Test-Driven Development, or TDD, is a software development process that is well described in a number of books, articles and on the web. Often Test Driven Development is mistakenly perceived as an alternative to Business Driven Development because of the similarity of the names. In fact these two are completely orthogonal – while BDD is a business strategy, TDD is a development process strategy. In other words, BDD is more about what to do, while TDD is more about how to do it.
Here’s a summary of the best practices based on my personal experience with it.
First, it is about tests and testability. You have heard that good quality software has attributes such as scalability, maintainability, reliability and so on. In this long list of -ilities you will usually find testability either at the very bottom or missing entirely.
While I was trying to find the right place for testability in this list, I came to the realization that it is in fact a prerequisite for the other software quality attributes, not one of them. For example, how reliable is software if there are no automated tests? Can it be maintainable if it is not understandable? Can it be available if it is not controllable?
Whatever the software development strategy dictates for the software quality priorities, testability is a must have.
Second, TDD is about defining the order: tests first, then implementation.
You probably heard that it does not matter when you define or write the tests - that what is important is that you have them.
Wrong! This is a trap. I have never been involved in or heard of a project where the tests written afterwards are a sustainable and beneficial part of the project. Why? There are many reasons, one of which is that writing multiple tests is very expensive. Doing it just for the purpose of reducing the regression issues and costs is not worth it. It may take between one to two thirds of the time it takes to develop a feature. Appending this time to the schedule is almost never acceptable.
Writing tests only makes sense if they are written before - or at least at the time of the implementation.
The third thing about TDD is that the testing is happening in the development. The responsibility for testing and in general for the quality of the software product should never completely get out of the developers responsibilities. In fact I believe it is mostly the developers’ responsibility, but this is a topic for another day.
There are a lot of factors that software architects and designers need to take in consideration when a software system and the accompanying harness is designed and implemented. Never forget the testability. Leaving the testing to the QA team explicitly is a bad idea and usually results in a very expensive testing process … or bad software quality.
Developers co-own software product quality and TDD is a very good place for them to start contributing.
Tips for implementing TDD in your project
- Make writing tests easy. It is hard to do something when it is hard. And it is easy to do something when it is easy. Invest in the necessary infrastructure and framework in your development process to make it easy.
- You are going to spend a lot of time writing your tests – do everything necessary to put them to work for you - integrate them with the development process and add them in CI and/or nightly build systems. It is common knowledge that the sooner you find a problem the cheaper it is going to be fixed.
- Having good test coverage opens additional possibilities for improving the quality. Take advantage of all of them. Regularly run dynamic code analysis and track the results. Add runtime code checks (e.g. asserts) to validate that your code is running correctly.
- Create visibility – run code coverage reports. I have no idea why humans work like thais, but there is no better motivation for something than measuring it.
- Do not assign a single developer to do the testing. It makes sense only if everybody does it.
- If you just want to try it first, do not use your less experienced developer – use the most experienced one.
- Involve the quality engineers in the process - the tests resulting from TDD are a big investment and you cannot afford your quality team to ignore them in their risk analysis and test strategies.
What you will discover using TDD:
- Writing tests before is exciting and gives the feeling of accomplishment vs. writing them after that feels like a chore
- Once your developers are educated on TDD and see the value for themselves, you won’t be able to stop them from using TDD even if you want to
- New to the project and junior software engineers will be able to fix bugs and implement new features that were unfeasible otherwise
- Including test coverage does not increase the required development time
- Refactoring is not such a scary process and you can do it on a regular basis
- QA engineers love to work on projects with good test coverage
Getting started with TDD is not easy, and with some projects it can be hard to see where to start. If you have any questions drop them in the comments, and I'll be happy to lend my advice.