“A team of smart committed individuals will almost always deliver working software,” someone shared this piece of wisdom with me long ago. While there is good amount of truth in this statement, especially regarding the ‘working’ part, I have often wondered if that working software will be maintainable too. What if one such smart developer likes to code using bulky classes and long methods? In my fifteen years of software development experience, I have often run into perfectly working pieces of code that were a nightmare to enhance – with methods running into hundreds of lines and classes into thousands. Not to mention, there is no way one could expect meaningful unit tests for such code.
Test Driven Development (TDD) is the practice that ensures working software is built in small chunks of manageable pieces, in small iterative mode – thereby producing modular code that is readable and maintainable. And, the best part is – it creates a regression test suite (of unit tests) as a by-product.
During our 4-hour long session on Test-Driven Development this Saturday (Apr 18), we started with short overview of the practice, then spent good amount of time actually practicing it. The audience came from various backgrounds, with good representation from QA and project management, most working in .Net domain and one in PHP. Yet technology proved no barrier for the enthusiastic group when it came to trying out a TDD example in Java. Eclipse and JDK were quickly installed, and coding soon ensued. Besides TDD, the participants also practiced pair programming during the session.
It wasn’t long before the first failure brought cheers on everyone’s face. Moments later, the first little working piece of code brought more enthusiasm. The TDD cycle of test/code/refactor had begun. The lack of Java development background posed some challenge and slowed down things a bit, but by the end of the session, everyone had successfully completed a few TDD cycles.
During our discussions, we also touched upon BDD (Behaviour Driven Development) and discussed how it is different from and yet complements TDD – while one focuses on automating functional/integration (black-box) tests, the other takes care of more granular testing (unit testing).
The question that keeps coming back in TDD sessions is – is TDD good for small projects or big projects? And, can it work for my project?
The short answer is TDD is good for all projects that require coding. Because TDD is not a new technology or tool, it is a practice, or good programming discipline. You still code in the language you do – be it .Net, Java or something else. You just need to shift focus from ‘Happy Path Development’ of coding all the way till the end and testing thereafter – to building code progressively through short test/code/refactor cycles. This behaviour shift ensures the working software is in line with requirements, has been tested rigorously, and is highly maintainable to facilitate future changes.
I would like to stress the maintainability part –because the only featuresthat have not been touched after they were built are those that either belong to a dead project, or are never used.
Happy coding… one little piece at a time!