No change without a failing test

Motivation

The adage “If it ain’t broke, don’t fix it” underscores the importance of being cautious with changes in software development. While resisting change can be prudent, it’s crucial to understand that changes inherently carry risks. Ensuring that a test case fails before making modifications provides concrete evidence of a bug. This practice helps avoid unnecessary disruptions and promotes more thoughtful, data-driven decision-making.

Applicability

Before initiating any changes, especially those for which you may be held accountable, it’s vital to have a clear rationale. A good practice is to prove the existence of a problem—this involves creating or modifying a test that reliably fails before implementing a fix. While the effectiveness of test-driven development (TDD) may vary in some contexts, establishing a method to verify changes is essential.

Application

1. Identify the Issue: Before making changes to the code, clearly identify the problem you intend to solve.
2. Create a Failing Test: If a relevant test does not already exist, create a new test case that represents the bug. This test should fail under the current code conditions, providing a baseline for validating your fix.
3. Implement the Change: After confirming the existence of a failing test, proceed with the necessary code changes to address the issue.
4. Run the Tests: Execute your test suite, including the newly created test case. If the test passes, it indicates that your change successfully resolved the issue.
5. Maintain Automated Tests: Ensure that automated tests are in place to prevent regressions in the future. This commitment helps safeguard against introducing new bugs when further changes occur.

Consequences

By adhering to the principle of “no change without a failing test,” development teams enhance code quality and maintain higher test coverage. This practice leads to clearer test cases that help define expected behavior. While there may be an initial overhead in setting up tests, the long-term benefits far outweigh these costs.

Conclusion

The practice of demanding a failing test before making changes fosters a culture of accountability and rigor in software development. By ensuring that changes are supported by test cases, teams can mitigate risks and enhance the reliability of their codebase. This method ultimately contributes to smoother development cycles and a more robust software product.