Skip to content
GetProfitable
Search

Forward testing, the bar magnifier and Deep Backtesting

Lesson 21 · about 11 min

A backtest ends at the current bar. Everything after that is forward testing: the strategy running on bars it has never seen, in real time, with you watching. It is slower than any backtest and it is the only test that includes the parts the emulator cannot model. This lesson covers how to do it with TradingView's tools, plus two tester features that change what the historical results mean.

Forward testing on TradingView

There are three levels, in increasing realism:

  1. Leave it on the chart. The strategy keeps trading the live bar; the tester's trade list grows. The equity curve after your last edit is out-of-sample by construction. Note the date and bar where you stopped changing the code. This is free and requires nothing else, and it is the minimum.
  2. Alerts into a journal. Add alert_message to entries and exits and create an "Order fills" alert with a webhook to a spreadsheet, a notes app or a logging endpoint. Every simulated fill is now timestamped outside TradingView, which prevents the temptation to "fix" the script and quietly restart.
  3. Paper trading. TradingView's built-in paper trading account can take orders from the trading panel, and some connected brokers offer demo accounts. Placing the strategy's signals by hand for a few weeks teaches you the real latency between signal and fill, what a gap does to your stop, and whether you actually follow the rules at 09:31.

What to compare after a month: forward expectancy and profit factor against the backtest's. Expect worse. If forward expectancy is negative while the backtest was strongly positive over hundreds of trades, look for repainting first, then costs, then overfitting.

Recreate alerts after every change

An alert snapshots the script when created. Any edit to the code or inputs means the running alert is testing an old version. Recreate alerts after every change, and record the version in the alert message so the journal shows which rules produced each fill.

The bar magnifier

Module 6 explained that when both a stop and a target fall inside one bar, the emulator guesses the order using the open-to-high versus open-to-low distance. The bar magnifier replaces the guess with data. With use_bar_magnifier=true in the declaration (or the checkbox in Properties), the emulator loads lower-timeframe bars for each chart bar and walks through them to decide which order filled first.

//@version=6
strategy("Magnifier demo", overlay=true, initial_capital=10000,
     default_qty_type=strategy.percent_of_equity, default_qty_value=10,
     use_bar_magnifier=true)

Facts about it:

  • It is a paid-plan feature; on other plans the setting is ignored.
  • The intrabar timeframe is chosen automatically and there is a limit on how many lower-timeframe bars can be loaded, so the effective history shortens on low timeframes.
  • It changes fill order and fill prices for stop and limit orders, not the signals themselves. A strategy whose results move a lot when the magnifier is toggled was depending on the guess; treat its non-magnified results as unreliable.
  • It does not fix lookahead, repainting or liquidity. It only refines intrabar sequencing.

Run every strategy that uses strategy.exit with both settings and compare. If your plan does not include the magnifier, prefer stops and targets far enough apart that both rarely fall in one bar, which usually means testing on a lower timeframe than the one you signal on or accepting wider levels.

Deep Backtesting

The tester normally only sees the bars loaded on the chart, which for intraday timeframes may be a few months. Deep Backtesting, on paid plans, runs the strategy over a longer history than the chart displays, with a date range you choose, and shows the results in the tester only.

Its limits shape how you use it:

  • Results appear in the tester, not on the chart: no trade arrows, plots or tables for the extended period.
  • Some script features are unavailable or behave differently in deep mode; when a script uses something unsupported, the tester tells you, and you cannot compare like for like.
  • It is a separate run you trigger deliberately, and it is slower.
  • More history is only useful if the data is what you would have traded. Continuous futures contracts are back-adjusted; long stock histories include splits; crypto history before a venue existed is stitched.

The right use is sample size: turning 80 trades into 400 so that module 7's uncertainty argument is answered. The wrong use is finding the one long window where the curve looks best.

A testing sequence that holds up

  1. Develop as an indicator; guard signals with barstate.isconfirmed; use the [1] lookahead idiom for higher timeframes.
  2. Convert to a strategy with commission, slippage and risk-based sizing.
  3. Read per-trade statistics; require 100 or more trades, more across symbols.
  4. Tune on in-sample only; check out-of-sample once; test parameter neighbours.
  5. Toggle the bar magnifier; use Deep Backtesting for sample size where available.
  6. Freeze the code, note the date, and forward test with alerts into a journal for at least a month or 30 trades.
  7. Only then, size according to the drawdown you can survive, and keep the journal running.

Key idea: Forward testing is the only test that includes what the emulator cannot model; the bar magnifier replaces guessed intrabar fill order with data; Deep Backtesting buys sample size, not certainty.

Try it: Freeze one strategy today. Write the date and bar index in its description, create an order-fill alert to a journal, and do not edit it for four weeks. At the end, compare forward expectancy with the backtest.

Recap

  • Forward test by leaving the strategy on the chart, logging fills through alerts, and paper trading the signals by hand.
  • Recreate alerts after every change and version the message.
  • use_bar_magnifier=true resolves stop-versus-target order with lower-timeframe data; results that change a lot when toggled were relying on the guess.
  • Deep Backtesting extends history for sample size, with fewer visuals and some unsupported features.
  • Freeze the code, note the date, and judge the system on trades it had never seen.

See it drawn

Original diagrams for the ideas on this page. Illustrative, not real market data.

The spread of outcomes behind an expectancyA histogram of forty trades: a tall block of small losses on the left, a low spread of larger wins on the right, and a line marking the average outcome.NUMBER OF TRADES051024 LOSSES, AVG −$20016 WINS, AVG +$600EXPECTANCY +$120−$400−$200$0+$200+$400+$600+$800PROFIT OR LOSS PER TRADEexpectancy = (40% × $600) − (60% × $200) = +$120 per trade
Expectancy: the average trade. Forty trades sorted by outcome: 24 small losses and 16 larger wins. Weighting each side by how often it happens gives the average result per trade, marked here by the dashed line at +$120.
One daily candle broken into four six-hour candlesA tall daily candle on the left and the four six-hour candles that make it up on the right, with dashed lines linking the day's open to the first candle and the day's close to the last.ONE DAILY CANDLEFOUR 6-HOUR CANDLEScloseopenhighlow=00:0006:0012:0018:00one dayThe same trading, summed up in one bar or spelled out in four.
How timeframes stack up. A daily candle is not different data, only coarser data: it opens where the first six-hour candle opened, closes where the last one closed, and its wicks reach the highest and lowest prices any of the four touched.
An equity curve and its drawdownAn account balance rising over a year, falling from a peak to a trough, then climbing back to the old peak.ACCOUNT EQUITY$20k$12k$8k024681012TIME (MONTHS)PEAK $16,000TROUGH $12,000DRAWDOWN−25%RECOVERY
Equity curve and drawdown. An account balance plotted month by month. The fall from the $16,000 peak to the $12,000 trough is a 25% drawdown, and the shaded area lasts until the balance climbs back to the old peak.

Finished this module? Take the module quiz.