Topics / Engineering practice
Find slow tests without removing the protection they provide.
Measure execution cost, identify what each expensive check establishes, then decide whether to optimize, move or selectively run it.
Use actual durations and a representative environment.
Separate queue time, setup time and test execution. Compare repeated runs before treating one slow result as a stable property. A test can be valuable and expensive; the decision is how to get its evidence at the right point in delivery.
Proof can read supported result files and list tests at or above a duration threshold. It reports recorded durations; it does not benchmark the test environment itself.
proof test slow results.xml --threshold 10Use the report produced by your runner. Confirm that the report includes the execution time you mean to optimize.
Preserve the obligation while changing the test.
Illustrative example
A database restart test takes a minute.
Replacing it with a mocked success response makes the suite faster but stops exercising recovery after restart. Keep a real recovery check at the appropriate gate. Optimize fixture setup or isolate the slow scenario rather than claiming the mock establishes the same behavior.
| Option | Check before adopting it |
|---|---|
| Reuse fixtures | State cannot leak between tests |
| Run in parallel | Shared resources and timing do not change the claim |
| Select affected tests | Missing links trigger a broader run |
| Move to a later gate | The consequence and release policy permit the delay |
Measure the whole trade-off.
Track execution time, flakiness, missed failures and maintenance effort. Proof’s requirement links can help explain which promise an expensive test protects. A duration list alone cannot tell you which tests are safe to delete.
Try it on your software
Bring a slow suite and its result report.
We will separate expensive setup from consequential evidence and choose a bounded improvement.