Define the indicator mechanics and your data assumptions
Trend Intensity Index is an indicator-style measure that converts price behavior into a quantified trend-activity value. To backtest it responsibly, first define the exact formula you are using, including:
- the input price field(s) (for example, close only vs. other fields),
- the lookback or window length,
- how the value is scaled or normalized,
- how you handle missing bars, daylight gaps, and session boundaries.
Then define the backtest data rules. Use the same bar construction you would observe in live conditions (bar timeframe, timestamp alignment, and whether indicators are computed on the bar close or using available intrabar data). Document assumptions for every calculation example so another person can reproduce the series from your raw data.
Separate stable mechanics from variable market or provider conditions
A common failure mode in indicator backtesting is treating historical outputs as if they come from the same execution environment you would face in practice. Keep two ideas separate:
- Stable mechanics: the indicator transformation from past prices to an indicator value.
- Variable conditions: market regime changes, differences in liquidity, bid/ask spread behavior, and how orders would actually fill.
Even when you do not simulate trades, you still need a consistent rule for what the indicator value means at the moment you would act (for example, “computed using information up to the previous bar”). If you do not freeze this timing rule, results can reflect look-ahead bias.
Model costs, execution constraints, and position handling
If your backtest includes any performance metric that depends on trading, you must include costs and execution limits, because they often erase optimistic indicator findings. In a responsible setup, costs are not “afterthoughts”; they are part of the experiment design.
At minimum, specify assumptions for:
- transaction costs (commissions, spreads, or a conservative total cost rate),
- whether fills occur at bid/ask or mid, and how slippage is treated,
- how often you rebalance or enter/exit (rule frequency matters),
- how you handle partial fills or order latency (even a simple cap can be better than ignoring execution).
Also decide what “signal use” means. If you use the indicator to define a state (for example, trending vs. non-trending) rather than as a standalone trade trigger, describe that state rule explicitly and test it as a classification problem over time.
Control bias with strict evaluation design
Indicator backtests are vulnerable to multiple biases. Design your experiment to detect them rather than hide them:
-
Parameter overfitting: If you try many window lengths or thresholds until performance looks good, you may fit noise. Use a limited search space and record what you searched.
-
Look-ahead bias: Ensure the indicator value used at time t only uses information available at or before the decision time.
-
Data snooping: If you test many hypotheses and only keep the best, reported performance is inflated.
A practical bias control method is walk-forward validation (also called rolling or out-of-sample evaluation). For example, choose a training period to select parameters, then test on the next contiguous period without re-tuning. Repeat across several folds, and summarize stability rather than a single peak outcome.
Include at least one material limitation and a failure mode
At least one limitation should be tested openly. A common failure mode for trend-activity indicators is that they can perform well in one regime (smooth trends) and poorly in others (range-bound or sudden mean-reverting conditions). Another failure mode is sensitivity to timeframe: the indicator can behave differently on 1-minute bars versus daily bars.
To make this concrete, run a regime stress test by splitting the backtest into different market states (for example, based on realized volatility or trend strength proxies). Compare whether the indicator’s relationship to your chosen evaluation target holds across regimes, not just in one period.
Verify with out-of-sample checks and reproducibility
A responsible backtest should enable independent verification. That means:
- the code or calculation steps are reproducible from the described inputs,
- the same indicator mechanics are used in both training and testing,
- out-of-sample results are computed without re-optimizing after the split,
- results are reported with uncertainty-aware thinking (for example, comparing distributions across folds rather than relying on a single best run).