Demo forward test, explained
A demo forward test is a validation exercise where you test a trading approach on time periods that were not used when creating or tuning it, but you do it in a demo (paper) environment rather than with real money. The purpose is to see whether the approach still behaves in the forward period under your planned rules, not to prove profits.
A worked example is a fully specified scenario that states: (1) what rules you test, (2) what dates or forward window you use, (3) how you measure performance (and why), (4) which costs or constraints you assume, and (5) what could go wrong.
Mechanism: what “forward” and what “demo” change
Forward means the evaluation happens after the approach is finalized. This matters because historical relationships can be misleading: patterns seen in the past might not persist.
Demo means orders are simulated by a platform or provider. This can differ from live conditions in at least four ways:
- Execution realism: fills and timing may be smoother than real trading.
- Costs: spreads, commissions, and slippage can be modeled differently.
- Liquidity and market impact: demo may not replicate how depth changes at your trade size.
- Operational behavior: platform connectivity, order handling, and latency can be different.
So, a demo forward test is mainly useful for process validation: did you follow the rules correctly, and did the approach react to new conditions as expected?
Evidence-style worked scenario (with explicit assumptions)
Below is one transparent scenario you can use to understand the steps. Numbers are simple and illustrative; they are not based on live prices.
Assumptions
- You test one fixed entry rule and one fixed exit rule. No changes are allowed during the forward window.
- You use a forward window of 10 trading days not used for designing the rules.
- You execute at the next bar open after a rule trigger. (This is an assumption about timing.)
- You assume a constant transaction cost of 0.50% per round trip on the notional position. (This stands in for spread + commission + typical friction.)
- You measure results per trade using a simple return model:
- Trade return = (price move in your favor or against you) − 0.50%.
- You start with a notional position size of 1 unit per trade for simplicity. You are not modeling margin.
The worked example
Suppose your rules produce exactly 5 trades during the 10-day forward window. The price moves (before costs) you observe in that forward window are:
- Trade 1: +1.20%
- Trade 2: −0.60%
- Trade 3: +0.40%
- Trade 4: −1.10%
- Trade 5: +0.80%
Apply the cost assumption (0.50% per round trip):
- Trade 1 return: 1.20% − 0.50% = +0.70%
- Trade 2 return: −0.60% − 0.50% = −1.10%
- Trade 3 return: 0.40% − 0.50% = −0.10%
- Trade 4 return: −1.10% − 0.50% = −1.60%
- Trade 5 return: 0.80% − 0.50% = +0.30%
Now compute basic summary metrics (chosen only to illustrate the mechanics):
- Total return across 5 trades = 0.70% − 1.10% − 0.10% − 1.60% + 0.30% = −1.80%
- Win rate = 2 winners out of 5 trades = 40%
- Average winner = (0.70% + 0.30%) / 2 = +0.50%
- Average loser = (−1.10% −0.10% −1.60%) / 3 = −0.93%
What you learn from the example
- If your approach was designed expecting positive forward performance, this forward outcome would show a mismatch.
- If you were designing for robustness (not a specific profit), you would still learn something: the approach’s behavior under new periods depends heavily on costs, timing assumptions, and how demo execution approximates real execution.
Limitations and failure modes
A demo forward test can fail to answer the real validation question if any of the following happen:
- Rule changes during the forward window: if you tweak rules after seeing forward results, the test no longer measures forward performance. 2. Optimistic execution assumptions: if demo fills are smoother or costs are understated, the results can look better than live trading would. 3. Small sample size: a handful of trades can produce misleading win/loss patterns by chance. 4.