A backtest can make a bad strategy look brilliant. Remove slippage, let the code peek one bar into the future, optimize one parameter too many, and the equity curve starts acting like a sales page.
The job of a backtest is not to prove that a strategy works. The job is to find every realistic way it can break before real money gets involved.
A useful trading backtest tests rules on historical data with realistic costs, no future leakage, out-of-sample validation, and regime checks.
If it only looks good on the exact period and parameters you optimized, it is not a strategy yet. It is a curve-fit candidate.
| Test layer | What it catches | Failure sign |
|---|---|---|
| Clean data | Bad sessions, rollover gaps, missing bars. | Results change when contract handling is fixed. |
| Real fills | Slippage, commissions, intrabar assumptions. | Profit disappears after normal costs. |
| Walk-forward | Overfitting to one sample. | Optimized settings fail on unseen data. |
| Regime split | Trend/chop/news dependency. | One market state creates all the profit. |
Start With the Rules, Not the Chart
Write the entry, invalidation, target, session, risk limit, and no-trade conditions before you run the test. If the rule changes every time you see a losing trade, you are no longer testing. You are negotiating with the past.
A clean rule should be boring enough that another trader could code it without asking what you “kind of meant.”
The Three Numbers That Matter
Net profit is the least useful first number. I care more about maximum drawdown, average R, and whether the results survive after costs are raised.
Bad result: 62% win rate, great equity curve, no slippage, no commissions, same optimized settings on one month of data.
Better result: 46% win rate, stable average R, realistic costs, moderate drawdown, similar behavior across multiple unseen windows.
Use separate in-sample and out-of-sample periods. Include commissions and slippage. Test multiple regimes. Track losing streak length. Export the trade list and review the worst 20 trades by hand.
When a Backtest Is Ready for Sim
It is ready for simulation only when the rules are stable, costs are included, the worst-case drawdown is tolerable, and the strategy still makes sense after you inspect individual trades.
Then run it in replay or SIM with the same order logic. A backtest that cannot survive realistic execution is not ready for live size.
Write It Up Like a Due-Diligence Memo
A backtest report should not read like a victory lap. Start with one paragraph: what was tested, which market, which period, which costs, what the result means, and what decision follows. Do not bury the caveats — if the system only works in low-volatility ranges, say so on page one.
Then show the assumptions table before any equity curve: rules, data handling, costs, sample windows, trade distribution, drawdown, regime split, the worst trades, and the next-step decision. Look at the distribution, not just the average: clustering, outliers, long flat stretches, and whether one week created the whole year.
Do not go live yet. The strategy survives costs and out-of-sample windows, but underperforms during high-volatility news weeks.
Next step: add a news filter, rerun the same windows, then run 20 simulated sessions with order-state logging.
Source and risk notes
- CFTC materials warn that hypothetical results have limitations and do not represent actual trading: CFTC education.
- NFA investor resources explain futures trading risks and the need to understand costs and leverage: NFA Investor Best Practices.
- Backtests are research tools, not performance promises.
Final rule: a backtest is not a trophy. It is a stress test for your assumptions.
