What Is Test-Driven Development?
Test-driven development, or TDD, is a software development process commonly used in Agile.
Introduction to Test-Driven Development
What Is a Test?
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.
Testing 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.
What Is Test-Driven?
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. What is important is that you have them.
And that's just wrong!
It's a trap. It's rare for tests written afterwards to be a sustainable and beneficial part of the project.
Why? There are many reasons, one of which is that writing multiple test scripts 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.
What Is Test-Driven Development?
The third thing about TDD is that the testing is happening in the development. The responsibility for testing and the quality of the software product is the developers' responsibility, too.
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.Back to top
6 Test-Driven Development Best Practices
Make Writing Tests Easy.
If something is difficult, it's difficult to do. And it's easy to do something when it is easy. Invest in the necessary infrastructure and framework in your development process to make it easy.
Integrate Testing Into Your Process.
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.
Improve Test Coverage.
Having good software testing 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 Into Testing.
Run code coverage reports. Test reporting will motivate your team.
Include Everyone in Testing.
Do not assign a single developer to do the testing. It makes sense only if everybody does it. If you just want to test the waters with one developer, choose your most experienced developer first.
Get QA Involved.
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.Back to top
Benefits of Test-Driven Development
- Writing tests before development is rewarding. (Afterward, it's a chore.)
- Once your developers are educated on TDD and see the value for themselves, TDD will become the norm (and your product will benefit).
- Better test coverage improves quality and accelerates development.
- Showing test results increases satisfaction.
- You'll be able to fix bugs and implement new features faster.
- QA engineers love to work on projects with good test coverage.
Getting Started With TDD
Getting started with TDD is not easy, and with some projects it can be hard to see where to start. But, when you use the right testing tools, TDD is a whole lot easier.Back to top