TDD: Not For Design
Recently I was having a discussion about NoSQL and Relational Databases. The positions are so divided. It always harkens back to the day when parallel and linear processing were raging in battle against each other.
So tell me, do you multi-thread your apps that much? How about in a method? Why not? right. Cause you don’t need to. Parallel and linear processing have their places. So do NoSQL and RelationDB’s. And so does TDD.
TDD stand for test driven development. There are times I’ve heard the word “design” substituted for development. There are still people banging Khrushchev’s shoe on the cube and screaming “WE MUST DO TDD”!!!!! Because they think it is the best way to code an application. It will dictate your design, which will be rock solid because you have done TDD!
Great, in theory, on the surface.
TDD vs. well — Test after? Is also one of those dead end arguments. They are just merely tools. Try as a TDD Cleric might try, its just a damn tool to use and is not well suited for most design work. I’m sorry, its not. But some still people use it to do design for their code. And development is a creative effort. Development is not typing fancy.
The reason TDD is poor for design is tough to grasp; because it takes more insight than a sound byte or a simple dismissal. The reason comes after a long time of trying TDD, and finally having that aha moment. it reminds me very much of putting tarragon on fruit loops. You eat the fruit loops and something just doesn’t taste right. And you don’t know what it is, just something. If you happen to like tarragon on your fruit loops, then I suggest instead imagine coco puffs with rabbit shit. Mmmmm delicious rabbit puffs . . .
TDD doesn’t work because the tests are not the source behavior of the application. I am sorry but they are not. You can code the tests first, but before that, the application had already existed in the form of a requirement or more likely, someone’s mind. The application already exists before the tests so it is already designed.
A BA didn’t come along and say “I think our business needs a set of test suites for customer registration.” Nope.
They wanted customer registration. The test doesn’t dictate where the entry fields are, where the submit button is — all that comes after the real design and merely tests that it matches the criteria. That’s it. NOTHING is driven by the tests. In fact, the idea of “driven” becomes silly in that context. Driven implies “first.” And the tests are not first.
Between the requirements and the translation of them into code, which may be tests, there weren’t tests. The tests are derivative.
Now let me support this with field data. I have talked to 4 places in the last month that all state they are a TDD shop on paper. But when you look at their code, when you talk to them — well, they aren’t doing it! They have those zealot TDD programmers onsite that will kill you if you speak out against Ruby and even they aren’t doing it. all the time.
In fact, a huge problem in the development world is that we do not get time to re-factor properly — the business does not want to pay for it and eats the technical debt. TDD then in fact becomes a deterrent to re-factoring because it takes more time with more code.
The idea of TDD is good, as a tool. It’s nice as a way to supplement the quality of your code, or to help decide if there are patterns. You have to be willing to throw whole sets of tests out for re-factors; and a lot of people won’t do that so like a distributed repository it never really gets properly practiced.
But TDD is not suited for most design and never will be. The world is not manifested like that.