Red Green Refactor

Structure: A team member creates a test for a change that has not yet been made. The test is run. If it passes (green) then this indicates that the change would be unnecessary, as the desired conditions are already satisfied. If it fails (red) then this proves that the conditions are not yet met. The change can then be made and the test run again. If the change has been implemented successfully then the test will pass (green). The code is refactored to improve design, performance, or other qualities that may have been impacted by the change. The test is re-run and if this refactoring has not compromised the desired behavior, then the test will still pass. Previously written tests should also be run before any change is committed, as other tested code may have been compromised by the modification.

Applicability: Test Driven Development is applicable to all forms of development. It is also applicable for maintenance and repair. For example, if a flaw is discovered a test can written that expresses the desired behavior. The test will fail, and a fix then introduced, at which point the test will pass.

Consequences: Test Driven Development is a significant culture change for many teams and throughput may initially drop as the practice beds in. Introducing TDD may be controversial in organizations with a separate QA testing function. However, productivity generally increases in line with improvements in code quality, and reduced rework can be expected. The practice also encourages a better understanding of requirements and their acceptance criteria. An automated test environment is recommended to gain the full benefits of TDD, since all tests should be run before any change is committed.