Test Driven Development
The origin of TDD
- TDD was developed/rediscovered by a computer scientist by the name of Kent Beck in the late 1990s. Kent Beck, the creator of Extreme Programming formalized TDD to improve the developer experience and in turn dramatically improve application quality.
- The practice of test-first development where planning and writing tests were done before development took place was first used by NASA's Project Mercury. In doing so they shortened overall development time as the NASA test group was able to write tests based on requirements and limits before their programmers implemented those features.
- During the dot.com boom companies needed to develop software faster and faster in order to stay competitive. TDD was invented to help teams build high-quality features with ever-shortening product life cycles.
- Agile, a renowned development methodology and extreme programming spin-off, emphasizes TDD as a core practice in the pursuit of quality application development.
Pitfalls of TDD
- Inexperienced developers and engineers can spend time writing irrelevant or unhelpful tests that do not ensure the app functions correctly.
- Slow testing frameworks can hinder developer experience, making developers unhappy and ineffective.
- TDD is a skill that must be trained. While all developers are using some type of testing feedback loop to figure out if their programs are functioning as intended, not all developers are doing so as efficiently as they could. Regardless, TDD requires an upfront investment in the training of engineers, project managers, and even designers.
Benefits of TDD
TDD and the strategies and skills it encompasses helps developers build high-quality software in several ways.
- TDD requires developers to use less brain-share to remember what works and what doesn't, which is a majority of what differentiates a good developer from a bad one.
- TDD allows developers to spend less time testing each feature as they develop. Because their tests can be run by a computer, developers, while tests are running in the background, can spend time thinking about how to code the program.
- TDD allows developers to start where they left off as they are guaranteed methods to function as they do in passing tests. Taking a break incurs less of a penalty as the developer can spend less time upon their return familiarizing themselves with how the program works.
- TDD is self-documenting, as developers can see examples of method calls by looking at spec files. This allows developers to see the intended use of a function without having to figure it out by reading documentation (which may be out of date, inaccurate, or written in a foreign format)
- TDD eliminates developer fear, by giving them proof that what they built works the way they think it will. In doing so, developer confidence increases as they dramatically increase the quality of their work and become happier, less defensive, and more proud of what they built.
Why do people avoid TDD?
Building without Test Driven Development seems faster. And for the first few features it certainly is.
Naive development vs. Test-Driven Development.
When first developing your app, detecting regressions takes zero time (because you have no existing features to break). When you have a simple app with one feature, detecting regressions zero time, if the feature works there are no regressions. If the feature doesn't work you have a regression.
One place where the app can work improperly.
Most teams ignore the importance of detecting regressions and focus on the speed of initial development. However, as the number of features in your application grows, the time to detect regressions will grow exponentially. Unfortunately if you don't start the project writing tests, you won't find this out for yourself until it is too late.
More places where the app can work improperly.
Test Driven Development focuses on minimizing the time to detect regressions (during development), rather than minimizing initial feature development time. As the number of features grow, managing whether or not existing features are still working becomes increasingly important.
Lots of places where the app can work improperly.
For many engineering teams, the norm is to develop many features of the application, then manually test to see if anything broke. If they find something they'll then go back and try and find the bugs / fix them.
Developing one feature without TDD and automated testing.
With TDD, engineers are able to minimize the time it takes to detect and locate these failures, dramatically decreasing the overall development time of the application. As engineers are adding new features the system is notifying them if anything in the codebase is breaking as a result of their work.
Three important aspects of test driven development:
- Realtime notification of failures in the app
- The cause of the failures
- The location of the failure points in the app
Developing three features with TDD and automated testing.
Some tips when following TDD
- Establish nested user stories
- Implement unit tests for business logic
- Implement integration tests for each user story
- Minimize the time each test takes
- Run tests in parallel
- When developing, run just the tests that should pass for the feature(s) you are currently working on. Then periodically run all tests to ensure you have not caused any regressions.
About us
Raidon is an award-winning design and development company. We've developed a proven process based on TDD to create quality applications faster than baseline development. We've used this process to build applications that have allowed our clients like Third Wave Automation to raise over $40 million.
