lancerkind

I do this too in cases where I’ve got an “extreme” amount of learning to do. (Learning a new language, a library, or something I’m trying to make work just simply won’t do I break it down into a tiny test).

This isn’t my usual TDD workflow but I use it when my understanding of the mangauge or language feature are blocking me.

I like your points about when working with a new developer and how it creates intermediate goals. Are you Pair programming when doing this?

Nicely said @voodootrucker. And I agree with @Tashoecraft. Lots of people get value from TDD. Unfortunately, some don’t and assume it’s the TDD process that’s broke. Its not the tool’s fault. It’s also understandably difficult (though not rational) that groups of people have trouble adopting new practices like TDD. Agile Thoughts podcast exposes some of the social blockages starting with episode 14: https://agilenoir.biz/series/agile-thoughts/

Regarding your first paragraph. It sounds like your mixing up the TDD workflow with ATDD. ATDD uses a requirements level view (macro test) and those concepts are usually well known before starting development. So you can write those tests upfront before development.

TDD is about writing tests as you build the design. You’re not supposed to write a bunch of micro tests before writing any code. Rather you want to write a single micro test, then write a little code, when the test goes from red to green, you then enhance your existing test or add another test, then add a little more product code. So the effect is growing your tests as you grow your product code. Episode 12 illustrates this workflow for a simple example: https://agilenoir.biz/podcast/012-an-example-of-doing-tdd/

The TDD series starts with episode 9 and is still continuing as of episode 15. https://agilenoir.biz/series/agile-thoughts/

This is tough to do in a listening medium. Episode 12 covers a simple example that expresses the workflow and give you the general idea. https://agilenoir.biz/podcast/012-an-example-of-doing-tdd/

Getting a copy of “TDD by Example” or buying a video course will get you further.

Some software languages or platforms are easier to do TDD in than say proprietary computing "appliances" in proprietary languages. You've mentioned Python, which is a pretty flexible language and conducive to doing TDD. Do you do most of your project work in Python?

You mentioned getting bug fix requests. How many times over the year do requests like this interrupt your other project work? On average, how much of your effort does servicing such requests (research, meet over them, plan a fix, then do the agreed upon fix and test the agreed upon fix, deploy the fix) take? Hours, days,...?

Thank you for that. I've got the idea now. In these projects, are you responsible for the maintence and later code changes? Or are these projects one time deliveries and someone else handles things from then on?

Also, if you don't mind my asking, how many years of experience did you have in working in the IT industry when first trying your hand at TDD?

I'm curious how much time was spent trying to write test driven code before deciding it wasn't working for you. Did you succesfully write a few small programs using TDD (coding katas)? Or did you apply TDD to your project at work? For how many hours or lines of code did you try TDD before deciding it wasn't going to work?

I'm interested in your test later approach. When you're attempting 100% branch coverage, do you sometimes find writing the test later causes redesign of the product code? On average, how many days does it take to complete a cycle of: write the code and then write automated unit test code? What ratio of that time is spent doing test automation versus writing production code?

Thanks for the TDD study reference. I collect these and I haven't seen that one.

How was TDD presented/introduced to you?

Regarding coverage comment, your right in that code can contain capabilities (or bugs) beyond the TDD coded conceived. (If they weren't conceived then it could be a bug or things that don't happen in practical operations.) The TDD people are right in that if you follow the TDD process, all your code comes up as covered by a code coverage tool. But this is only coverage. Not all possible functionality coverage. I imagine "all possible functionality coverage" is an intractable problem in the same class as the Halting Problem. Branch/line coverage should be near 100% for TDD code. (Some I/O coupling areas are intentionally saved for other types testing as they aren't unit testable.) It's an easy thing to measure. It's a common industry metric. It's not the whole picture but it is something.

Measuring code coverage on TDD created software that was built without monitoring the code coverage, then later use code coverage at the end as an evaluation: I've only a few anecdotal (two) instances where I did this and I found the code coverage to be well above 95% for the code base and at 100% for modules that were pure logic. In one of those instances, after many rounds of defect injection, I discovered one or two locations where another unit test could be added.

All in all, I've been pretty happy with TDD. But who cares? I want to hear from the industry why others aren't doing it. :-)

Thank you eesmith, I enjoyed the discussion!

How about hearing some more from others? What's stopping you from doing TDD? Is it because you don't believe it? If you don't believe it, how was it presented to you? Did you try it?

It's the same: successfully giving them the goods and service they want (laughs, a cool website, a web API). Being able to identify what interests them during a conversation is a master skill.

Let me say it another way: if you have a great business idea, tell everyone you can find about it and learn from their reactions/questions what's working in your pitch and not working.

The process of explaining something is very valuable. As a science fiction writer, when I tell someone a summary of a story I wrote, I can read in their expression or verbal "uh huhs" what's drawing them in and what's distraction from the heart of the matter.

As a business owner, the same process applies. I describe to them what I'm doing, and I can see the evaluation process at work in their face as to whether they get the value I'm trying to create or not. (Or put another way, if the value I'm explaining is actually valuable or not.)

In both cases, I may do nothing and let it fall the way the cards may and then hear their feedback, OR I may make adjustments in real-time as I read the listeners body language and use that as cues to feedback into my value proposition (visit my biz, read my story).

Comedians are masters at finding the heart of a dialog and adjusting (like jazz musicians) what they say to maximize the effect.