A decent article, have claps, but I still disagree with the ending. Strict TDD, writing the test before the code, slows your velocity and renders your code less reliable than brutal, adversarial testing of your own code right after you have written it will do.

I am obsessive with my testing, but I just never write unit tests before the code. Often I will write acceptance tests quite early, but then I won't deliver those tests till close to the end.

In the early stages of writing code, the first hour or two, I am constantly tweaking and sketching what I am going to do, and having tests would offer only negative benefits, as the whole API is in flux.

Often I sketch the top level, and then drop down to the lowest level to implement some part I can completely specify, and then go back to the top level. At this phase, I'm most interesting in implementing components that I think might be hard, not obvious stuff.

And when I "implement" that low level part, that means extensive automated testing, typically unit tests.

But until I have written the tricky part, I don't really know which bits I am most likely to have fucked up in, and so I cannot write effective tests.

In TDD codebases, I see too much testing of things that are certainly not broken, and less testing of edge cases or dodgy interactions between components. We have a limited amount of time to develop, and so our testing time should be disproportionately spent on areas more likely to have hugs.

To me, the early phases of testing involve me ruthlessly ferreting out the bugs I know are in there, and I am going to do that by any means necessary. I have no qualms about testing a private method if I believe it's a chink I can use to find a bug.

But when I go back to the top level, I don't write any tests at all - yet. I'm still putting together the high level code, and so I have nothing specific to test yet.

Down with TDD! Up with BTD, "Brutal Test Development"!