The Failures of “Intro to TDD”

Totally agree about the dissonance with TDD and it always surprised me it wasn't discussed more when TDD was going through the hard sell stage.

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.

I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code.

I find that most new developers instinct is to do exactly the opposite - i.e. write the first line of their main function, then realise it needs, say, an argument-parsing class, so start writing that, then realise that needs a logging class, so start writing that, etc. which means you have to keep much more stuff in your head at once, you end up writing much more code in each commit than you should, and the distinction between bits of code at different levels of abstraction often ends up much blurrier which leads to messier design.

This seems to be quite easily countered though - just pointing out to people the difference between breadth-first and depth-first styles can have quite an immediate effect

This article sums up the problems I've seen with TDD first hand. I've never seen a team end up with a better design than they would have using the old maxim: "Think hard. Then code.". I'm sure they exist, but adopting TDD does not automatically lead to better design, that much seems certain.

Another issue with TDD is that it is incredibly difficult to reason about. In many groups, there are at least one developer sold on the concept, and when I voice my concerns with the methodology they immediately demand an explanation why I "hate testing", or alternatively preach about all the goodness of unit testing. Which of course isn't the issue at all. Many developers seem to confuse TDD and unit tests, and the supposed benefits of the former is very hard to quantify.

Methodologies aren't a substitute for creativity or intelligence.

At best they can give a person with good judgement a different angle to look at their problems with.

At worst they are thought-stopping slogans that turn a gullible novice into a crippled novice.

Hexagonal architettures combined with a command processing pipeline help in defining test boundaries and entry points. Those entry points are your public interfaces, everything beneath shouldn't need any test. The entirety of the core application behaviour is testable in isolation by design. You basically end up writing mini acceptance tests for your domain logic.

I think that's a preferable approach for complex systems, the "redundant tests" issue is not a problem and end to end tests are reduced to just a few proving everything is hooked up.

His steps 4 through 6 seem to completely violate the principle of YAGNI. It also seems way too much like big-bang releasing. You write all this code for a very long time and don't have any way to objectively say the design is correct (in that it actually performs the business case from start to finish) until the very end.

I've designed systems in this way before (strangely, they always seem to be some sort of document validation), and they always turn into complete hairballs of code that eventually gets thrown away and something much simpler substituted.

Now, I just stick to DRY, YAGNI, and "Compression-Driven Development" http://mollyrocket.com/casey/stream_0019.html

I wish I had time to write a decent post. Lacking time, I'll try to be concise. If you want to really understand the benefits of TDD, the best book I know on the subject is actually Michael Feathers, "Working Effectively with Legacy Code". It is rather dense and getting a bit dated, but by showing you what you need to do to improve legacy code in a methodical fashion, he provides the basis for learning how to do good TDD.

I can't detect any difference between his proposed approach and Harlan Mills's Top Down System Development. Basically, he's going to take this 'traditional' team and introduce them to the hot new development methodology of 1970, all while showing no awareness that he has done so. What's that saying about people who don't understand history?

At least they won't have to change the acronym.

BDD got it right. Write your tests to prove the features are working, not to prove that the code written to implement the features does what it does.

I've found the way TDD has been "sold" to me as quite odd, and probably what's turned me off from it the most (cure of all ills). At the same time, I find the religious pushes for and against to be both understandable and bizarre. I've been thinking about this for some time now, but don't think I've ever really written it down.

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.

The tl;dr of this article - some programmers _really_ need to get exposed to a Systems Engineering course.

The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.

Any discussion about TDD requires a link to Rich Hickey's Hammock-Driven Development talk: https://www.youtube.com/watch?v=f84n5oFoZBct

The important thing that TDD or any other software design methodology is trying to accomplish is getting you to think about the design of your programs. However you want to accomplish that is fine as long as you take some time before you open your editor and think before you start writing code. It doesn't necessarily have to be TDD.

Here's a recent post I wrote about reasons for and approaches towards TDD. Generally, I love it. I find an API evolves though as you build it, so for me, it's a bit more about "tests at the same time" and "tests as the primary and first way of exercising the code". Also, that tests do better when they test use cases at a higher level, and that unit tests (I do agree with the article in some ways here) are often written at a level which penalizes refactoring, when they could be instead automated tests at a higher level.

http://michaeldehaan.net/post/120522567217/the-case-for-test...

A better description of the audience you were teaching to would be super helpful, because how you teach needs to be tailored to the crowd. Making a generic statement like you will never start with TDD anymore doesn't make sense.

To be frank, when you said the audience was 'typical enterprise java developers', it seems that you are already describing a group of developers who are sort of 'stuck' in their ways, who maybe haven't heard of other things like TDD and WOULD necessarily miss the point of a lot of it.

Just sayin - it could be helpful to avoid broad statements like "never start with TDD" that may be more audience specific.

This sounds a lot like "Think first, then code". I like the approach, and have more or less been applying it unknowingly since I read Martin Fowler's Agile book during Uni. Nice article!

I've been doing TDD for nearly 10 years and this article describes my experience in a way I have not been able to distinguish myself. Thank you.

I have just come onto a project that has tests up to the armpits, mocked everything, and the test lead wielding an almost evangelical bent across the developers. And the codebase and system is still shit. Why? Because the team though loads of tdd and bdd equals a great system. Wrong. They can help, when used sparingly, but to make them your design methodology, praying at the church of testing dogma is insane. So, no tests bad. Worse, over testing. When I see fourteen tests to one code unit, I know now to run away.