Having been involved in test-driven projects over the past 2 years, I found myself explaining the advantages and disadvantages that test-driven introduces to software projects to many people whom I taught, trained or coached.
I always stuck to the usual points, for instance, “design by usage”, “safety-net for your code”, “faster drilling to the heart of the problem”, “provides documentation for your code” etc. These are all great advantages for the project, and everyone in the project (including management) eventually enjoys them.
Lately I have been asking myself – why is TDD good for me? How do I profit from it? What’s in it for me? And most important: Why do I deliberately get myself into TDD adventures and even dare to say that I enjoy it?
Well, the answer is simple: Test Driven Development allows me to be an idiot, and keep getting paid for it.
When writing code, I face two tightly-related problems: Functional requirements (making sure my code does what it’s supposed to do) and design requirements (making sure the code is simple, efficient, coherent, extensible etc.).
Solving both these problems is a big headache, and I often find programmers failing to provide a solution for both of them. I often find poorly designed code which answers its requirements or well-designed code which does not.
TDD allows me to split this headache into two manageable problems.
Following the Red-Green-Refactor mantra carefully, I start with writing horrible, horrible code which answers the requirements. I continue making it all the way to the green stage and continue iterating until I have a hefty, sloppy method which answers all its requirements.
From that moment on, I do not need to worry about the functional requirements any more as my code is already obliged to solve them by unit tests, and any slight shift from that obligation will immediately come to my attention.
This is the part the real fun sets in. I have the freedom to design (actually, redesign) without worrying about breaking functionality. Like a lucid dream, you can do whatever you want, without the risk of getting hurt.
This way I can concentrate on each phase separately:
When answering requirements, I just have to make sure the code does what it is supposed to do, even at the price of code duplication, inefficiency and plain ol’ dumb code.
When refactoring, I have a well-set environment that allows me to apply design techniques without worrying about functionality.
This raises a question – can the role of the modern developer be split to two as well? A less-experienced developer will handle functionality and a more experienced developer will refactor?
If you liked this article, !