TDD processes are the core set of practices. Successful implementation of TDD depends on practices described in this section.
Benefits: It ensures that testable code is written; it ensures that every line of code gets tests written for it.
By writing or modifying the test first, the developer is focused on requirements before starting to work on the implementation code. This is the main difference compared to writing tests after the implementation is done. The additional benefit is that with the tests written first, we are avoiding the danger that the tests work as quality checking (QC) instead of quality assurance (QA). We're trying to ensure that quality is built in, as opposed to checking later whether we met quality objectives.
Benefits: It confirms that the test does not work without the implementation.
If tests are passing without the need to write or modify the implementation code, then either the functionality is already implemented or the test is defective. If new functionality is indeed missing, then the test always passes and is therefore useless. Tests should fail for the expected reason. Even though there are no guarantees that the test is verifying the right thing, with fail first and for the expected reason, confidence that verification is correct should be high.
Benefits: It ensures that there are no unexpected side effects caused by code changes.
Every time any part of the implementation code changes, all tests should be run. Ideally, tests are fast to execute and can be run by the developer locally. Once code is submitted to version control, all tests should be run again to ensure that there was no problem due to code merges. This is especially important when more than one developer is working on the code. Continuous integration (CI) tools should be used to pull the code from the repository, compile it, and run tests, such as:
- Jenkins (https://jenkins.io/)
- Hudson (http://hudson-ci.org/)
- Travis (https://travis-ci.org/)
- Bamboo (https://www.atlassian.com/software/bamboo)
Benefits: The focus is maintained on a small unit of work; implementation code is (almost) always in working condition.
It is sometimes tempting to write multiple tests before the actual implementation. In other cases, developers ignore problems detected by existing tests and move towards new features. This should be avoided whenever possible. In most cases, breaking this rule will only introduce technical debt that will need to be paid with interest. One of the goals of TDD is that the implementation code is (almost) always working as expected. Some projects, due to pressures to reach the delivery date or maintain the budget, break this rule and dedicate time to new features, leaving the task of fixing the code associated with failed tests for later. These projects usually end up postponing the inevitable.
Benefits: This type of refactoring is safe.
If all implementation code that can be affected has tests and they are all passing, it is relatively safe to refactor. In most cases, there is no need for new tests. Small modifications to existing tests should be enough. The expected outcome of refactoring is to have all tests passing both before and after the code is modified.