Direct answer
A worked example of forward testing is a fully spelled-out scenario where you take a set of rules and evaluate them on later, unseen data. The key requirement is that every assumption used in the calculation is stated. That lets you independently reproduce the steps, check the arithmetic, and see whether the outcome depends on market changes or on the assumptions you chose.
What forward testing means (mechanism)
Forward testing evaluates a trading approach using time periods that come after the data used for designing or fitting it. In practice, people often compare:
- Backtesting: performance on past data (often used to tune choices).
- Forward testing: performance on a later period that was not used for tuning.
A “worked example” typically includes the following inputs:
- Rules (decision logic): clear, testable conditions for entering and exiting.
- Timeline split: which dates/times are used to develop the rules and which are reserved for forward testing.
- Data used in the forward period: prices/observations for the later time window.
- Execution model assumptions: how orders are assumed to fill (e.g., using a specific price convention).
- Costs: commissions, spreads, or other friction modeled consistently.
Forward testing is conceptually stable, but the details are variable because real execution differs from simplified assumptions.
A worked example with explicit assumptions
Below is a simplified numerical example. It is not intended to predict real outcomes; it shows the mechanics.
Setup
- Goal: evaluate a rule that creates at most one position at a time.
- Rule (example): Enter a long position when a signal is present; exit after a fixed holding time of 2 price bars.
- Forward period: 5 consecutive bars labeled 1 to 5.
Assumptions (state everything)
- No leverage constraints are modeled (just cash P&L).
- Position size: $1,000 notional equivalent per trade.
- Contract price convention: you compute profit using percentage change in a single “price” series.
- Entry and exit prices: assume you get fills at the bar’s quoted close for both entry and exit.
- Costs: assume a flat cost of $2 per trade (covers spread/commission in a single number).
- Signal schedule: the rule triggers on bar 1 only.
Forward test data (prices)
Assume the price values in the forward period are:
- Bar 1 close: 100
- Bar 3 close (exit, because holding time is 2 bars): 104
- Bars 2, 4, 5 closes are irrelevant because the rule triggers only once.
Calculations
- Trade count: 1 trade (trigger on bar 1).
- Gross return (percentage): (104 − 100) / 100 = 0.04 = 4%
- Gross profit: 4% of $1,000 = $40
- Net profit after costs: $40 − $2 = $38
Recording the result
A minimal forward-testing record for this scenario would include:
- Period dates (the split between development and forward windows)
- Rule definition
- Entry/exit mapping from bars to prices
- Position size
- Cost assumption
- Net P&L and any risk measures you choose to compute (with formulas)
The “worked” part is that you can re-run the same arithmetic if you accept the assumptions.
Limitations and common failure modes
Forward testing reduces a specific risk—evaluating on data you already used to tune—yet it does not guarantee reliability.
Material limitations and failure modes include:
- Assumption mismatch: fills at “close” in a model rarely match real execution. Slippage, spread changes, and latency can change outcomes.
- Market regime change: the forward window may reflect different volatility or correlation than earlier periods, so results can reverse.
- Overfitting through repeated attempts: if you repeatedly adjust rules after looking at forward results, you effectively leak information from the forward window.
- Cost sensitivity: small changes in the assumed costs can flip profitability, especially when edge is small.
- Small sample effects: short forward periods or few trades make results noisy; a single trade can dominate.
None of these issues can be resolved by forward testing alone; they require careful definition of the assumptions and consistent verification.
How to verify forward testing independently
Independent verification means you can reproduce the same logic and calculations from the described inputs. A practical checklist (still non-advisory) is:
- Confirm the time split: development data must be excluded from the forward window. 2. Check that the rules are unambiguous (what triggers, and what exits). 3.