Protection against regressions measures how well a test detects defects that make previously working functionality fail after a code change. Strong protection reduces false negatives by exercising meaningful code and asserting the outcome it produces. section 4.1 section 4.2
Evaluate the metric through three dimensions:
- Amount of executed code: broader execution generally creates more opportunities to reveal a regression, provided assertions validate behavior. section 4.1
- Complexity: complex logic offers more opportunities for defects than straightforward boilerplate. section 4.1
- Domain significance: failures in important business logic matter more than failures in incidental technical code. section 4.1
- Test accuracy: protection against regressions supplies signal by finding broken functionality, while resistance to refactoring limits false-alarm noise. section 4.2 section 4.6
Assert the rendered result
A test for MessageRenderer creates a message, calls Render, and asserts the complete HTML string. It protects the externally visible behavior better than checking the renderer list, source text, or internal algorithm, because those implementation details can change without changing the result.
Mock at the system edge
An integration test gains stronger regression protection by mocking IBus, the message bus’s external edge, rather than IMessageBus, an intermediate application wrapper. The test then verifies the message sent to the edge.
