How to Backtest a TradingView Strategy Across Multiple Stocks

What one TradingView strategy can test

The built-in strategy report describes the simulated trades of the strategy applied to the chart. Order functions such as strategy.entry() do not take a symbol argument. Reading a different ticker with request.security() does not change the instrument an order trades. A custom script can calculate its own basket statistics, but those calculations need their own execution and accounting rules.

Freeze a test protocol before changing symbols

Choose the stock universe and holdout period before reading the results. Save the script version and input settings. If you tune each stock separately, label the exercise as symbol-specific optimization and test the selected settings on unseen periods. It answers a different question from applying one fixed rule set across a universe.

• Record exchange-qualified tickers, chart interval, standard chart type, session, adjustment settings, and strategy account currency.
• Use the same requested start and end dates, then verify actual available coverage and enough earlier bars for indicator initialization. A date filter cannot create missing history.
• Choose a sizing rule deliberately: fixed cash, fixed shares, and percent of equity answer different questions. Percent-of-equity sizing compounds each independent account; it does not reserve money in a common portfolio.
• Document commissions, slippage in ticks, margin, order-processing settings, and historical fill assumptions. Use a consistent cost methodology, with symbol-specific costs where justified.
• Define how to handle open trades at the end date, unavailable symbols, short histories, and runs with no trades. Preserve these cases in the results.

Run, export, and reconcile each symbol

This is a proposed repeatable procedure, not a report of measured performance. Add the saved strategy to a chart, select a stock, and wait for its report to recalculate. Check the symbol and settings before saving results. In the strategy report, download trade data from the Trades tab, also called List of Trades in some layouts. TradingView documents CSV export separately from chart-data export.

• Create one run ID per symbol, strategy version, and test configuration. Save settings alongside the CSV because a filename alone cannot reproduce a run.
• Check the first and last available bars, the first eligible signal after warm-up, and the policy for any position still open at the end.
• Record closed-trade count, net profit, maximum drawdown, account currency, and open-position status from the report.
• After export, reconcile closed-trade count and net result with the report. Inspect the CSV schema before counting rows: entry and exit rows may represent the same trade.
• Repeat for the full predefined list, including losses and no-trade runs. Rerun one symbol with the saved configuration to check reproducibility.

Handle external data, sessions, and missing bars explicitly

Both indicators and strategies can request other symbols. For example, an MSFT signal on an AAPL chart can intentionally trigger an AAPL trade; that is an intermarket rule, not an MSFT backtest. Label the traded symbol and the signal source separately. Requested series are aligned to the chart timeline, so the chart session determines when the script can evaluate them.

• Align exported records by absolute timestamp and document the display timezone. Matching calendar dates does not imply simultaneous exchange closes; Pine timestamps and exchange timezones need separate treatment.
• Decide whether missing observations should block a signal or carry a prior value. barmerge.gaps_on can return na where no newly confirmed value exists; gaps_off fills gaps and can expose developing values in realtime.
• Audit higher-timeframe signals for historical/realtime differences. For confirmed higher-timeframe values, the documented pattern pairs a one-bar expression offset with lookahead_on and applies only when the requested timeframe is higher.
• Do not treat a carried-forward quote as a tradable new price. Record holidays, trading halts, listing dates, and unavailable history when comparing markets.

Why merging trade CSVs is not a portfolio backtest

A collection of independent accounts does not enforce shared buying power. Suppose a hypothetical account allocates 10% to each new position and receives 12 simultaneous signals: accepting them all requires 120% exposure before costs. A portfolio model must specify which trades are accepted, resized, or rejected. Sorting existing CSV rows does not recompute the trades that those decisions would change.

• Also model fees, spreads or slippage, borrowing costs where relevant, and available liquidity. Preserve cost assumptions when moving data between tools.
• A weighted combination of independent equity curves can describe a fixed-sleeve allocation if each sleeve has assigned capital and aligned valuations. It still does not model money moving between sleeves unless that transfer is explicitly simulated.
• Trade CSVs alone may lack the price history needed to value open positions. Label a closed-trade equity curve as such rather than presenting it as mark-to-market portfolio equity.

Interpret the cross-stock comparison before optimizing

Review the distribution of results, trade counts, and coverage rather than only the best ticker. A profitable subset can depend on one sector or period. Current index constituents also omit former members; a historical universe needs point-in-time membership and delisted securities where available. If those data are unavailable, state the survivorship limitation. Testing more sectors does not remove it.

• Separate development, selection, and holdout results. Do not reuse the holdout to keep adjusting the rules.
• Treat no-trade and short-history runs as distinct outcomes, not silent exclusions or evidence that the rules generalize.
• Compare nearby parameter settings and cost scenarios, then record whether the interpretation changes. There is no universal stock count that proves a strategy works.