Define the concept before backtesting
Fibonacci Retracement is a way to mark potential price levels between two chosen points on a chart (often a start and an end of a swing). The method typically draws horizontal lines at fixed ratios of the distance between those points (for example, levels commonly labeled using Fibonacci ratios). It is best understood as a repeatable measurement procedure on historical price data, not as a guaranteed trading rule.
Responsible backtesting starts by making the “repeatable measurement procedure” explicit: what chart data you use, how you pick the two swing points, which retracement levels count, and what decision rule you apply when price reaches (or fails to reach) a level.
Separate stable mechanics from variable conditions
A backtest can easily become misleading if variable conditions are mixed together. Keep two categories separate:
- Stable mechanics (your defined process)
- Data definition: timeframe (e.g., minute, hour, daily), the price field used (open/high/low/close), and whether you resample.
- Swing-point selection rule: how you decide the start and end of the measured move (for example, based on local extrema using a fixed lookback window).
- Level definition: which retracement ratios are included and how you treat “touch” versus “close through.”
- Evaluation rule: what constitutes a “hit,” how far price must move after a hit, and the measurement window length.
- Variable conditions (market and execution realities)
- Costs: spreads, commissions, and fees.
- Execution: how orders are filled when price moves quickly, and whether you assume fills at the bar’s close or at a level during the bar.
- Regime changes: volatility and liquidity can shift over time.
A responsible approach uses the same mechanics across all test periods while allowing cost and execution assumptions to be varied within plausible ranges.
Make assumptions explicit and choose a consistent data setup
Backtesting quality depends on clear, stated assumptions. Even if you use the same indicator logic, different assumptions can create different results.
Key items to document:
- Swing identification: If swing points are selected manually in a backtest, the test risks hindsight bias. Prefer a rule-based approach.
- Look-ahead prevention: Ensure the swing-point decision uses only information available at the time the swing ends (or at the moment your evaluation starts).
- Bar-handling: Decide how a retracement “touch” is detected on OHLC bars. For example, does using the high/low mean intrabar touches count even if the close never reaches the level?
- Position sizing and holding logic: If you simulate outcomes, define holding duration or exit conditions in a way that can be computed from historical data.
Without these definitions, any performance figure is hard to interpret and easy to overfit.
Include costs and execution assumptions as first-class inputs
Many backtests fail because they ignore the economic frictions that can dominate small edge. Even when you avoid recommending trades, you can still evaluate the indicator’s behavior under realistic assumptions.
Consider modeling:
- Transaction costs: spread/commission/fees per round-trip or per action.
- Slippage: a rule for the difference between the intended entry/exit and the achieved fill.
- Fill convention: whether you assume orders fill at the level price, at the bar’s open, at the bar’s close, or using an intrabar approximation.
If your backtest cannot state these inputs, it cannot be responsibly interpreted. A good practice is to rerun the same logic under multiple cost/slippage scenarios and observe whether conclusions remain stable.
Control for bias and overfitting with robust checks
Bias often appears when rules are tuned until they “look good” on one historical segment. Use bias controls to reduce this risk.
Practical controls include:
- Parameter sensitivity tests: If your swing detection uses a lookback length, vary it within a reasonable range rather than using a single chosen value.
- Walk-forward testing: Train/tune on earlier periods, then evaluate on later periods without re-tuning.
- Purge/embargo ideas (conceptually): Avoid testing periods that overlap heavily with the data used to define events in a way that would leak information.
- Blind evaluation: Decide all rules before seeing future performance, then apply them.
These checks do not guarantee correctness, but they make it harder for accidental structure to masquerade as an edge.