We don’t have time for tests
At lunch I had the familiar conversation about how TDD/pairing are fine unless you’re under pressure to deliver, and then …. you just do whatever it takes. Well, if you don’t think TDD/pairing are “what it takes,” then why do you /ever/ work that way?
Dave Nicolette
Same thing here. I was talking with a potential customer the other day and he said “for most projects here we don’t have time to write tests, we just code like hell to get them finished as soon as we can”. Well, but writing tests, for me, *is* the way to get it finished as soon as I can. The moment when we’re under pressure is the moment we should stick to good technique the most.
One example of this is a nice coding competition by Lasse Koskela and Markus Hjort at XP Days Benelux 2006. The objective of the game was to write a program to play Indian Poker (a silly, fun version of Poker) and win against other programs. The whole competition lasted less than three hours. As you can imagine there was not much time to waste :-) So what did we do? (I was pairing with a young chap from Philips who didn’t know much Java, so I, well, kept the keyboard all the time.) As I mentioned in my earlier report on the event, We wrote an acceptance test and then we used TDD. We did drive *all* code with tests. And we won :-)
How did we win? Well, for one thing, half the other programs crashed. Ours didn’t. We decided on a simple strategy to decide when to “stay” and when to “fold”. Since we finished early and we still had something like 10 minutes, we decided to add an option of raising if the cards looked very good for us. Still driving code with tests. And you know what? At the last round only two or three programs remained. Our bot won by raising!
Three hours, a new API, a new problem. I did what it takes: to use the best programming technique I know. I don’t have time for working in a sloppy way.
March 27th, 2011 at 12:37
For my experience, writing test is *the* key to speed.
I’ve seen too much times a features developed in 10 minutes without tests that takes weeks to fix all regression and months to meet requirements.
May 4th, 2011 at 17:25
TDD is maybe better suited to a small programs than a complex application.
My point is, when making a small program, your unit test really test the program. This is also easy as the program do only a few things.
But most of the time, even if it not forbidden, TDD focus on unit tests. And after years of thoughts, I think unit test are not the most usefull ones. They tend to crash on any change. They tend to test the code you written (or wanted to write), but not the required functionnality.
What i really prefer is validation/integration tests. Here much more bad things can happen. The network can really be slow or just be down. You can find that despite all the meetings, module A and B made differents assumption and thus are not working well together. And the most important thing: Your tests allow to validate the big picture. You application is not just a bunch of small program performing trivial tasks. It is coherant software that do solve a real problem.
May 4th, 2011 at 20:07
Hi Nicolas,
Thanks for your comment. I think that both unit, “micro”-level tests and integration tests have a place. I disagree that TDD is better suited for small programs. Large programs are easier to write when they are built out of well-designed and well-tested modules.
You say that unit tests require a lot of maintenance. I find that may be a sign of a problem with the design of your production code. Have you read Growing Object Oriented Software [0]? I learned a lot from this book about writing tests that do not cost too much to maintain.
[0] http://www.growing-object-oriented-software.com/