Minimal

Test-Driven Development and mock objects

At work, we’ve recently moved to agile development methods and generally updated our practices. One of the things we’ve adopted is Test-Driven Development (“TDD”). From the things I’ve read and heard about it, you’d think it’s some kind of panacea, not only improving quality assurance, but also improving your code design.

From what I understand, TDD promotes highly-cohesive, loosely coupled designs — things we were taught to strive for at university, but which I’ve rarely created. Now, it’s really happening, but there was an uncomfortable hurdle to get over first. As with so many things that are evangelised, the downside of loose coupling was never really addressed.

From my experiences, loosely coupled classes tend to mean an increase in the amount of setup code you have to write in order to use them — setup code that has to be repeated everywhere you use the class. Such repetition is often cited as an evil thing elsewhere, so it seems to me that TDD is not without its downsides.

I still believe there are more pluses than minuses, mind. I’m now in a position to write automated unit tests and to use mock objects to keep an eye on the collaborations of the class under test. It’s a wonderfully reassuring safety net that I’ve never had before and there are many more benefits beside that. I just wish the evangelists of TDD were a little more open to acknowledging the trade-offs you would be making by adopting it.