What you will learn
- Unit tests
- Historical replay
- Cross-checks
- Failure injection
Unit tests
Verification should include unit calculations, state invariants and integrated event sequences. Tests that merely repeat the code's formula cannot establish independent correctness. Use hand-checked examples and adverse paths.
Historical replay
Compare a new implementation with a frozen baseline on identical inputs, then investigate every material difference. Expected changes should be explained; unexpected differences should not be dismissed because aggregate P&L improves.
Cross-checks
Test invalid and missing inputs, delayed responses and duplicate events. A system's ordinary behavior is only part of its correctness. Failure paths often determine whether state remains recoverable.
Failure injection
Separate software correctness from strategy effectiveness. A perfectly implemented losing rule is still losing; a profitable-looking backtest with implementation errors is not validated by its return. Both dimensions need evidence.
Worked example
A refactor changes trade timing by one bar but improves historical P&L. If timing was intended to remain unchanged, the improvement does not excuse the regression.
Try it yourself
Write acceptance criteria for a behavior-preserving refactor and a separate criterion for a deliberate strategy change.
Show the worked solution
The refactor should match the frozen decisions and accounting on identical inputs except documented nonbehavioral differences. A strategy change requires a new specification, version and independent effectiveness evaluation rather than being hidden inside the refactor.
Apply this to your course project
Build a demo strategy with unit, replay and failure-path tests.
Keep the calculation inputs, assumptions and decisions with your work. Practical exercises are self-reviewed; the scored knowledge checks assess the questions shown, not an independent certification of practical competence.