The Failures of “Intro to TDD”

The Failures of “Intro to TDD”
blog.testdouble.com

I guess my core problem is TDD only drives your design if you write quite granular tests but they then become barriers to further refactoring/redesign. However my current preferred approach (for anything non-trivial) is different to the authors. As he does I start out with outer-level acceptance-y tests, however those integration tests are then combined with extensive refactoring to drive the design, so I don't do the dreaming up of collaborators he does in step 4.

My reason for not thinking of collaborators early is although I think that approach has legs I found it didn't necessarily always the simplest/most elegant design you could come up with. I ended up encoding my first understanding of how to solve the problem into the interactions, even though I knew that my understanding of the problem at that point was much less than it would be once I dug a bit deeper.

Anyway with my current approach if I extract additional classes/whatever I might then test them directly, or use further tests to drive their design further (incl test doubles as appropriate). So I'll have one or a few tests of the extracted behavior at the outer level, and maybe more thorough testing at the lower level because quite often testing all the combinations and edge cases is easier at this level.

As a very general statement, I'd say any developer should try their hardest covers the basic tenets of TDD while working. Let me back that up, since I'm sure that's probably rubbed people up the wrong way.

1. I know what the system is currently doing

2. I know what the system should be doing

3. These things are different, and I know how to check

4. I change the system

5. I check that the system is now doing what it should be doing

That all seems pretty uncontroversial, I hope.

1. If you don't know what the system is doing now, you can't tell if there's anything to do at all.

2. If you don't know what it should be doing, there's no way of implementing it.

3. If you can't check that if it's doing the right thing (even manually) then you're fairly screwed (although we've all ended up in a case where the "check" is "ask the customer afterwards if it's fixed").

4. You obviously need to actually do something to change the system.

5. Finally you should check your work actually, well, works.

The idea that you have an automated check for 3 seems like a fairly good idea, as long as it's not too onerous. Then suggesting that it's implemented and run before 4 makes sense, it's unlikely to be much harder to do it before rather than afterwards and it gives me some confidence that the test checks what I think it does.

Personally, while I quite like the workflow presented, I'd do most of that on paper / whiteboard / in my head. Take the task and break it down into smaller things it needs to do. Don't rush into creating the right structure, just actually understand what it is this thing will need to do. Then I can consider general designs, where the edges will be, types of failures and errors that are likely to pop up and I can write something (as always, discovering more as it's written and having to change things). It's very useful to then start on the bits I'm less sure about, or the ones that will have the most impact if I have to change things. I think that gets easier the more you code though.