Test-driven development (TDD) writes tests before implementation code. A practical safeguard is to require the new test to fail before writing production code, then implement until it passes. The visible failure confirms that the test is active and capable of detecting the intended defect. section 1.4 section 10.2
Use the failure-first discipline to expose tests that are present but ineffective:
- Break the production code intentionally and verify that the test fails; a test that never fails may be malformed or assert only a weak fact. section 10.7 section 10.2
- Check that test methods are recognized as test entry points. A missing @Test annotation can leave functionality untested for years, while IntelliJ IDEA may omit the Run gutter icon. section 10.7
- Prefer assertions that establish the expected value over assertions that merely show that a value is not null or not equal to something. section 10.2
Make the assertion prove the change
A weak assertion checks only that the result differs from the old value: assertNotEquals("Check that content was modified", storage.getContent()); A stronger TDD-oriented check supplies the expected relationship: String oldContent = storage.getContent(); assertEquals(expectedContent, oldContent); storage.modifyContent(); assertNotEquals("Check that content was modified", oldContent, storage.getContent()); Then intentionally break modifyContent() and confirm that the test fails. section 10.2
Figure 10.2 Malformed test methods have no Run gutter icon.
Use the missing Run gutter icon as a quick visual clue that a test method may not be recognized. section 10.7
