TDD did not live up to expectations

Writing tests after the code has been written - to lock down behavior, quickly identify breakage, and support refactoring is a valuable process. But it's not the original vision of what constitutes test-driven development.

Your writeup mirrors my personal experience, which was why I was such an advocate for so long. But it doesn't mirror my team experience at all.

I bought Feather's book when it first came out and liked it so much that I bought copies for a whole team out of my own pocket. And I talked about and taught the techniques to the team members.

I had high hopes, and a good team, but the results that we got were not what I hoped for. The result we got was a lot of small tested functions throughout the codebase ("sprouts" in Feather's nomenclature) - which I expected - but I didn't see any evidence of coalescing of those tests into something better - and by themselves, the sprouts made the codebase worse.

I ran into a number of cases where I would pair with developers who were looking to do something better than sprout - so they could fix a whole class or area to be better - and the best answer I could give them is, "give me a morning and I can probably come up with a good solution", which doesn't really help. Some code is just aggressively hard to test.

And I should mention that this was pretty much the perfect environment to try this; I had a team without shipping pressure and a mandate from above to write better unit tests and sufficient time to train and pair with developers.

The approach we settled on was different. We spent our time looking for "targets of opportunity"; the problematic classes or groups of classes that were leading to real issues - bug farms, hard to modify, that sort of thing - and we took a targeted approach to replace them. The replacements were generally written using TDD.

Let me ask you - and by "you", I mean everybody reading this - a question.

If you had poor design or refactoring skills, how would you know?

Let's just say you've finished working on some code that involved writing new code. How do you know whether it's well-designed?

Well, you start by using your own sense of what is good design. But all of us can only see the things that we already know about, which us thinking that the code has decent design is only a sign that it is up to our level of understanding. This is a fundamental part of how knowledge works.

Code review can give some additional design feedback, but 1) code reviewers generally don't have time to give in-depth design feedback and 2) "you should redesign this" is generally not well received (see previous point about everybody thinking they are good designers), and I both have to work with my teammates and their comments factor into the kind of review I get. So, code review is not a good way to improve design change, even assuming that you have people on your team who have useful design advice to pass on and you are in the kind of environment that lets you be thoughtful about design.

If you are in a team with decent designers and your team pairs, then you are in luck; you have a good chance to expand your design skills. Leverage this at every opportunity.

Finally, it is possible to spend time (almost always your free time) learning more about design, doing katas, going to code retreats, etc. This also works.

And I'm sorry if this sounds arrogant; I've tried to find other ways of saying it.

I get your point, but it's not really about not doing TDD right. It's about TDD evangelists - and I used to be one of those - advocating that people should use TDD despite those people not having the skills to do TDD "right". And my experience is that not only is doing TDD without those skills not a fun experience, the resulting code is worse than if you let those same developers write the code the way they are used to, and maybe spend some teaching time on refactoring because it's a more basic skill.

> As such the tests often end up containing bugs

All code contains bugs, but we do not abandon programming. Having statements of behaviour from outside and inside the solution increases the chances that one will reveal a meaningful difference from the other.

> I just think the 100% test coverage TDD dogma is oversold and doesn't really work well in practice.

I work for Pivotal, one of the most outspokenly pro-TDD shops in the industry. I have, quite literally, never seen or heard any engineer mention test coverage ever.

> Of course I am not a fan of "methodologies" in general. I see them as attempts to replace thinking with rote formula.

I see them as a starting point. The expert mind sees possibility, but the novice mind needs certainty.