What is Test-Driven Development
Test Driven Development (TDD) is a programming methodology that reduces the time it takes developers to detect bugs in their code whereby increasing the speed of development and subsequently the quality of resulting code.
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?
Doing without TDD seems faster. And at first, it is.
Naive development vs Test-Driven Development
When first developing your app, detecting regressions takes zero time (because when you first start you have no existing features to break). When you have a simple app with one feature, detecting regressions also takes linear time.
Few places where the app can work improperly
That's why most teams ignore the importance of detecting regressions as they focus more on the speed of initial development. However, as the number of features in your application grows, the time to detect regressions will grow exponentially.
More places where the app can work improperly
TDD focuses on minimizing this time, rather than minimizing initial feature development time. And this becomes increasingly important as the number of features grows.
Lots of places where the app can work improperly
For many engineering teams, the norm is to develop the application, manually test the existing features to see if anything broke, and then go back and fix them.
Developing one feature without TDD and automated testing
With TDD, engineers are able to minimize the time it takes to detect these failures and dramatically decrease overall development time.
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.