Test Driven Development

Test Driven Development (TDD) is a software development approach in which developers write tests before they write code for new features. The code is changed to make the tests pass and subsequently, is refactored to meet the functional and non-functional requirements. This sequence of steps is repeated until all test cases for all features pass and can be marked as successfully completed. In TDD three activities are tightly interwoven: coding, testing (in the form of writing unit tests), and design (in the form of refactoring).

By validating them against a series of agreed-to tests, TDD— an Agile Testing practice—improves system outcomes by assuring that the system implementation meets its requirements. TDD, along with Behavior-Driven Development (BDD), is part of the test-first approach achieving Built-in Quality. Generally, XP follows this practice. These unit tests are run in an automated fashion during the build and integration stage. 

Primary phases of Test Driven Development

  • Create precise tests: Developers need to create precise unit tests to verify the functionality of specific features. They must ensure that the test compiles so that it can execute. In most cases, the test is bound to fail. This is a meaningful failure as developers are creating compact tests based on their assumptions of how the feature will behave.
  • Correcting the Code: Once a test fails, developers need to make the minimal changes required to correct the code so that it can run successfully when re-executed.
  • Refactor the Code: Once the test runs successfully, check for redundancy or any possible code optimizations to enhance overall performance. Ensure that refactoring does not affect the external behavior of the program.

Steps of Test Driven Development

  • The first step is to understand the requirements, feature, or the user story and write a corresponding test for it. The test case could be like a Junit or Nunit depending on the programming language used. 
  • The second step is to run the test case, which will obviously fail, because there is no valid code to execute. This is the red step.10 
  • In the next step, stubs of code are written that successfully compiles and can be invoked by the test case. At this stage if the test is run, it should call the code stub, but still fail because it lacks of functionality. 
  • In this stage, sufficient code is now written that makes the test case pass. One can hard-code return values, use constants, mocked-up objects and any other means to satisfy the test condition. This is the beginning of the green step. 
  • During the next stage, the developer keeps adding code to address the functional and nonfunctional requirements, making sure that the linked tests continue to pass. If there are more features to be added, new test cases have to be written first and the process repeats itself. 
  • In the refactor or clean stage, the code is updated to address any code quality issues, simplification of design, eliminate technical debt, remove any hard- coding, duplication, unused parameters, methods, classes, unnecessary log statements, etc. Note that while these technical changes are made, the behavior of the code is kept intact and the tests should continue to pass. 
  • The above cycle is repeated for each story, feature and functionality throughout all iterations.

Advantages of TDD

  • The programmer is forced to write only that amount of code that passes the test, nothing more than that, since it is wasteful. This follows the principles of “Do not Repeat yourself” (DRY).
  • If followed religiously, TDD could result in better code coverage and code quality. 
  • Since the success criteria are defined upfront, developers concentrate only on getting
    the test case to pass. This keeps the code simple and free from unnecessary clutter. 
  • A team following TDD naturally makes sure that user stories, when they are created, are testable (T in the INVEST acronym). 
  • The unit test cases are written in the same programming language and stored on the same version control repository where code is checked in – so the developers are not only familiar with it, but also own it. There is no need to maintain separate test case documentation elsewhere. 
  • With refactoring, there is a continuous focus to contain and remove technical debt, thereby making the code easier to maintain, make changes and understandable by the team. 
  • The suite of tests can be run over and over again (many times a day) to prove that the software continues to work irrespective of adding newer functionalities. 
  • The use of TDD shortens the feedback cycle, as once the code is written, built and executed, the test results are immediately ready in a matter of minutes. This supports the concept of frequent validation and verification. 
  • The successful outcome of TDD contributes to the ‘definition of done’.

Disadvantages of TDD

  • As the same developer who writes the tests also writes the code to pass it, so it is pretty much left to the imagination and level of interpretation of that developer. 
  • Not all code like that behind user interfaces can be reliably and efficiently unit tested. Teams will have to complement TDD with other forms of testing like exploratory testing to achieve the end purpose. 
  • Maintaining a test suite over the life cycle of the project is essential and should be a key consideration that the team will have to factor during their planning and estimation exercises. 
  • Forgetting to run tests frequently, writing too many tests at once, writing tests that are too large or coarse-grained, writing overly trivial tests, for instance omitting assertion and writing tests for trivial code, for instance accessors are few disadvantages of TDD.

Table of Contents (PSM ™, PSPO ™ & PSD ™ Certification)

  1. Scrum Framework – Scrum Theory
  2. Scrum Framework – Scrum Roles
  3. Scrum Framework – Scrum Events
  4. Scrum Framework – Scrum Artifacts
  5. Scaling Scrum – DoD – DoR – Scrum Framework
  6. Developing People and Teams
  7. Managing Products with Agility
  8. Developing and Delivering Products Professionally
  9. Evolving the Agile Organization – Scaled Scrum, Portfolio Planning & EBM

Recommended Practice Exams

Owner, PSPO, PSPO I, Scrum Open, etc. are the protected brand of Scrum.org. All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.

Scroll to Top