Pine Script Backtest Guide: How to Read the Strategy Tester

A Pine Script backtest is the process of running a strategy script over historical bars and listing the trades it would have produced. TradingView's Strategy Tester makes that easy to start, and just as easy to misread. The report looks precise, but every number in it depends on settings, on how the simulator guesses what happened inside each bar, and on the assumptions you gave it. This guide explains how to set up a Pine Script backtest, what each part of the report actually measures, and which biases quietly make results look better than they should.

It is a reading guide, not a promise that any strategy will behave in a particular way. For the wider question of why live results differ from tests, see backtesting vs live trading; for the statistical trap of tuning a script until it fits the past, see overfitting in trading strategies. This article stays on the tool itself.

What the Strategy Tester is

TradingView describes strategies as Pine Script scripts that can send, modify, execute and cancel buy and sell orders, and backtesting as recreating the work of a strategy on historical data. Forward testing recreates it in real time while the chart refreshes. The Strategy Tester (also called the Strategy Report) shows the output in tabs, typically an overview, performance and trade summaries, and a list of trades.

The key idea is that the tester is a simulation run by a broker emulator, not a record of anything that was executed. The emulator follows rules written down in the Pine Script documentation, and your results are only as realistic as those rules and your settings.

Settings that change the result

Open the strategy's settings and look at the Properties tab. According to TradingView's strategy properties help page, the main controls are:

• Initial capital and base currency. The starting balance the simulation uses. Percentage figures in the report are relative to it.
• Order size. A fixed quantity, a currency amount, or a percentage of equity. For futures, a fixed number of contracts is the most transparent choice, because it matches how a futures order is actually sent.
• Commission. Can be set as a percentage of trade value, a fixed amount per contract, or a flat amount per order. The default is zero, which flatters every result.
• Slippage. Measured in ticks and added to the fill price of market and stop orders.
• Verify price for limit orders. When enabled, the market must trade through your limit by a set number of ticks before the order fills, which is a more cautious assumption.
• Margin. The percentage of position value that must be funded.
• Recalculation options. Recalculate after an order is filled, or on every tick. The help page notes that calculating on every tick causes repainting on historical data.
• Fill orders. The bar magnifier option uses lower-timeframe prices to place fills more realistically on historical bars; a standard OHLC option forces real prices when the chart is Heikin Ashi.

The Pine Script documentation adds that the bar magnifier (the `use_bar_magnifier` parameter) is available on certain paid plans only, so check your own plan before relying on it. Deep Backtesting is referenced in TradingView's documentation as a way to keep the full trade history rather than the latest 9,000 trades, but we could not verify which plans include it as of 11 October 2026, so check TradingView's current pricing and help pages.

A minimal settings checklist

1. Set commission to what your broker and the exchange actually charge per contract per side.
2. Set slippage to at least one tick for market and stop orders, and treat any figure as an assumption to be tested live.
3. Use a fixed contract count that matches what you would really trade.
4. Decide whether limit orders should require a price move through the level before filling.
5. Use the same chart symbol and timeframe you will automate.

How fills are simulated

The Pine Script documentation explains that the emulator fills orders on historical bars using the chart's data. It does not see ticks inside a bar, so it assumes a path: if the open is closer to the high than to the low, it assumes the sequence open, high, low, close, and the reverse otherwise. Price-based orders assume no gaps inside a bar, and an order that would be crossed by a gap fills at the next bar's open. Market orders fill on the next available opportunity, which on historical bars is usually the next bar's open.

Two consequences follow:

• If your stop and your target both sit inside the same bar, the report can only guess which was touched first. A lower-timeframe view or the bar magnifier reduces this guess but does not remove it.
• A fill at a price the real market printed only for a moment is treated as a fill. Real queues, partial fills and thin liquidity are not modelled, which is why slippage and execution costs matter more than most reports admit.

Historical bars versus real-time bars

On historical bars, a script sees finished open, high, low and close values. On the live bar, those values change with every tick until the bar closes. A script that behaves one way on history and another in real time is the root of most repainting complaints. Strategy alerts add another point: they fire only for orders generated in real time, not for historical bars, so the tester's history and what an alert would have sent are never identical.

A glossary of the main metrics

Use these as vocabulary, not as targets. The numbers in your own report mean nothing without the settings above and a sensible sample.

Hypothetical arithmetic on costs

To see why commission settings matter, use invented round numbers. Suppose a strategy places 1,000 round-turn trades in a test, and the true all-in cost is $4 per round turn. Costs would total $4,000 over the sample. If the test left commission at zero, that $4,000 simply would not appear in the report. These figures are made up for illustration and do not describe any real strategy.

Biases that flatter a backtest

Repainting

TradingView's Pine Script documentation defines repainting as script behavior that makes historical and real-time calculations or plots differ. Common sources include values that fluctuate on the open bar, `request.security()` returning unconfirmed values on the live bar, and drawing pivots or labels onto past bars after they are detected. A signal that appears on the chart in hindsight was not available at that time.

Look-ahead

Using future data on historical bars happens most often with higher-timeframe requests. The documentation warns against using lookahead without an offset, because it leaks information from bars that had not closed yet. If a strategy only looks good with look-ahead enabled, the result describes the future, not a tradable signal.

Overfitting

Trying many parameter combinations and keeping the best one produces a fit to the past. Keep that as a separate discipline and read the dedicated guide linked above; here it is enough to say that more tweaks make a report look better and a live account no more reliable.

Survivorship, sample and regime

A test over a short window, one market condition or one contract can mislead. Futures also have contract rolls, so check how the continuous chart you test on is built, as explained in futures contract rollover.

A practical checklist before trusting a report

1. Commission and slippage are set, and you can say where each number came from.
2. The number of trades is large enough that removing the best three barely changes the picture.
3. The script uses confirmed bar data only (for example by acting at bar close), and has no look-ahead.
4. Results are stable when you nudge parameters slightly, not only at one value.
5. The test covers different market conditions, and you looked at out-of-sample data.
6. You compared the list of trades with the chart on a few days by eye.
7. You then ran the strategy in a simulation account in real time before any live size.

Where WeCore fits

WeCore does not replace the Strategy Tester; it picks up after it. If you build your own script in TradingView, you can connect its alerts to your broker or prop-firm account, apply risk limits you set, and run it in simulation mode first so you can compare real-time behavior with the test. Inside the WeCore app, the Strategy Builder (Tools, then Strategy Builder, needs an active Start, Prop or Fleet plan) can turn your own written rules into a strategy and backtest it on stored historical data with commission and no slippage, which is hypothetical and says nothing certain about the future. If you prefer ready-made logic, the WeAlgo strategies page describes what is available. You can look at the plans or create an account and begin with the simulation mode. Read how to set risk limits in WeCore before you go live.

FAQ

How do I open the Strategy Tester in TradingView?

Add a strategy to the chart and open the Strategy Tester panel at the bottom. Its tabs show the overview, performance, and the list of trades. Click the strategy's settings icon to change its properties.

Does the Strategy Tester include commission and slippage?

Only if you set them in the strategy's Properties. Commission can be a percentage, a per-contract amount or a flat amount per order, and slippage is entered in ticks. Defaults do not reflect your broker.

Why does my backtest look different from live alerts?

Backtests run on closed historical bars with simulated fills, while alerts act on real-time orders only. Repainting, recalculation on every tick and real fills explain most of the differences.

What is the bar magnifier?

It is a fill setting that uses lower-timeframe prices to decide the order of events inside a historical bar. It improves how stops and targets are sequenced but is still a simulation, and it is limited to certain plans.

Is a good backtest evidence that a strategy will be profitable?

No. A backtest describes the past under assumed costs and fills. Treat it as a way to find flaws, and confirm behavior in simulation before live trading.

This article is general information, not investment advice, and does not promise any result. Backtests are hypothetical, and past results are no indication of future results. Futures trading carries a high risk of loss.