The end of the test-first mania

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

It worries me that the tech industry is driven by such intense manias, which have cost me several jobs. For a long time you were not allowed to question Object Oriented Programming. I still go to job interviews and I’m asked the basics of Object Oriented Programming, and it is clear I have to say nice things about Object Oriented Programming or I won’t get the job. Thankfully none of these people ever check Wikipedia, where I am cited as a critic.

The same thing happened with testing, and “test first” almost gained that kind of monoculture that Object Oriented Programming did. As if there aren’t trade offs to every engineering decision, as if one approach is 100% good and 0% bad.

And these are smart people. Some of the smartest people in the world. But that intelligence doesn’t moderate the fanaticism. Rather, it feeds it. But 10 years later the same people will favor some other approach. But in the moment, they are happy to deny you a job, because you are not fanatic the same year they are, in the same way they are.

But, I’m not giving up on TDD because of the (well-known) difficulties in writing automated tests for GUIs. I’m giving up because I think it encourages conservatism in programming, it encourages you to make design decisions that can be tested rather than the right decisions for the program users, it makes you focus on detail rather than structure and it doesn’t work very well for a major class of program problems – those caused by unexpected data.

Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests.

It is easier to test some program designs than others. Sometimes, the best design is one that’s hard to test so you are more reluctant to take this approach because you know that you’ll spend a lot more time designing and writing tests (which I, for one, quite a boring thing to do)

The most serious problem for me is that it encourages a focus on sorting out detail to pass tests rather than looking at the program as a whole. I started programming at a time where computer time was limited and you had to spend time looking at and thinking about the program as a whole. I think this leads to more elegant and better structured programs. But, with TDD, you dive into the detail in different parts of the program and rarely step back and look at the big picture.

Source