TradingView’s Pine Script Strategy Tester runs on a bar-close evaluation model by default: strategies calculate at each bar’s close, and market orders fill at the open of the next bar. That single architectural fact explains most of the gap between a backtest that looks great and a live strategy that underperforms.
The three things the tester cannot simulate by default:
-
Intrabar fills. Historical bars carry no tick data, so the tester cannot see what happened between open and close. A stop or limit that would have triggered mid-bar is either ignored or approximated.
-
True tick-level liquidity and latency. Even with Bar Magnifier enabled, the tester uses lower-timeframe OHLC prices, not a real order book. Partial fills, queue position, and exchange latency are invisible.
-
Realistic execution costs. Slippage and commission default to zero, which almost always produces results that are too optimistic.
Your immediate next step: set commission and slippage to broker-like values, audit your request.security() calls for lookahead, then run a bar-replay comparison before trusting any headline number.
Key Takeaways
The Pine Script Strategy Tester is a bar-close model that cannot reproduce intrabar fills, realistic costs, or live execution dynamics by default, making forward testing and realistic cost configuration non-negotiable before deployment.
| Point | Details |
|---|---|
| Default model is bar-close | Strategies calculate at bar close; market orders fill at the next bar’s open, creating intrabar blind spots. |
| Zero costs overstate results | Set commission and slippage to broker-like values before trusting any headline performance number. |
| Lookahead is the biggest bias | Audit every request.security() call for lookahead_on; swap to lookahead_off and compare results. |
| Forward testing is mandatory | Paper trade for 4–8 weeks and run a small live rollout with explicit rollback thresholds before scaling. |
| Automation adds new risk | Alert latency, partial fills, and API rejections are invisible to the tester; log every alert-to-execution cycle. |
Table of Contents
-
What are the Pine Script strategy tester limitations in its default model?
-
Which Pine Script strategy() parameters change simulation behavior?
-
How do you detect repainting and lookahead bias in Pine Script?
-
Execution and automation caveats for live Pine Script strategies
-
Developer checklist: code and tests to harden a Pine Script strategy
-
A workflow to systematically identify and mitigate backtest biases
-
How TradingView’s strategy tester compares to professional-grade platforms
-
How do order-fill assumptions affect limit orders and Heikin-Ashi charts?
What are the Pine Script strategy tester limitations in its default model?
The Strategy Tester is a simulation engine, not a market replay. Understanding what it actually models prevents you from deploying a strategy that only works on paper.
The default execution model
By default, a Pine Script strategy evaluates its logic at the close of each historical bar. If that logic triggers an entry, the order is queued and filled at the open of the next bar. This is the “bar-close / next-bar-open” model, and it is the tester’s foundational assumption.
Historical bars contain no intrabar tick data. The tester has access to each bar’s open, high, low, and close, but it cannot observe the sequence in which those prices occurred. It does not know whether the high came before the low, or whether price briefly touched a level mid-bar before reversing. This creates a category of intrabar blind spots that no default setting resolves.
How alternative flags change behavior
Three strategy() parameters shift the tester away from the pure bar-close model, each with tradeoffs:
| Parameter | What it changes | Key tradeoff |
|---|---|---|
calc_on_every_tick |
Recalculates on every realtime tick | No effect on historical bars; can cause repaint |
calc_on_order_fills |
Recalculates up to four times per historical bar (open, high, low, close) | Improves intrabar approximation; affects reproducibility |
process_orders_on_close |
Fills orders at bar close instead of next-bar open | Reduces one-bar lag; can overstate fill quality |
The strategy() declaration parameters are documented in full in TradingView’s Pine Script reference. Enabling calc_on_order_fills is the most practical way to approximate intrabar events on historical data, but it still depends on OHLC history, not real tick sequences.
A concrete scenario
Suppose your strategy uses a moving average crossover. On a 1-hour chart, the crossover occurs 20 minutes into the bar. In the tester, the signal fires at bar close and fills at the next bar’s open. In live trading, the crossover triggers mid-bar, and your alert fires immediately. The fill price differs, sometimes materially, especially in volatile markets. That gap is not a bug in Pine Script. It is the model working exactly as designed.
Common ways backtests mislead you
Most overstated backtests share the same handful of root causes. Recognizing them before deployment saves real capital.
Repainting and lookahead bias
Lookahead is the most dangerous failure mode because it is invisible in the results. If your script calls request.security() with lookahead=barmerge.lookahead_on, it reads the closing price of a higher-timeframe bar before that bar has actually closed. The backtest sees the future; live trading does not. The result is impossibly good performance that collapses the moment you go live.
Repainting is a related but distinct problem. Some indicators recalculate historical values as new bars arrive, so the signal you see on a closed bar today may not have been present when that bar first closed. Strategies built on repainting indicators will show trades in the tester that could never have been taken in real time.
Intrabar fill mismatch
The bar-close model cannot distinguish between a bar where price touched a stop level for one tick and a bar where it held above that level all session. Both look identical in OHLC history. In gapped markets, overnight gaps or news-driven spikes can cause fills at prices far from the assumed next-bar open, a reality the tester does not model by default.
Unrealistic default costs
Zero slippage and zero commission are the defaults. For a strategy that trades frequently, even a modest commission per trade compounds into a significant drag that the backtest never accounts for.
Small sample size and overfitting
A backtest with 30 trades is not statistically meaningful. Optimizing parameters over a short history finds patterns that fit the past data specifically, not the underlying market structure. The more parameters you tune, the more likely you are fitting noise.
Which Pine Script strategy() parameters change simulation behavior?
Getting the parameters right is the difference between a model that approximates reality and one that flatters your strategy. Here is a practical reference.
Execution and calculation parameters
-
calc_on_every_tick: Recalculates on every realtime tick. Has no effect on historical bars. Useful for strategies that need to react within a bar in live trading, but it introduces repaint risk. -
calc_on_order_fills: Triggers recalculation after each simulated fill on historical bars, up to four times per bar. This is the most useful parameter for improving intrabar fidelity in backtests. -
calc_on_every_history_tick(where available): Extends recalculation to every available historical tick. Computationally expensive and limited by data availability. -
process_orders_on_close: Fills orders at the current bar’s close rather than the next bar’s open. Reduces the one-bar lag but can overstate fill quality for strategies that would realistically need confirmation. -
use_bar_magnifier: Uses lower-timeframe price data to simulate intrabar fills during backtesting. Available on certain paid TradingView plans.
Trade and cost parameters
-
pyramiding: Sets the maximum number of open entries in the same direction. Default is 1. -
backtest_fill_limits_assumption: Defines how many bars a limit order must be verified before it is considered filled. Critical for limit-order strategies. -
slippage: Sets assumed slippage in ticks per order. Defaults to 0. -
commission_type/commission_value: Sets commission as a percentage of trade value, a fixed amount per contract, or a fixed amount per order. -
default_qty_type/default_qty_value: Controls position sizing method (fixed, percent of equity, or cash amount). -
fill_orders_on_standard_ohlc: Forces fills to use standard OHLC prices rather than Heikin-Ashi values, which is critical when your chart uses Heikin-Ashi candles.
Pro Tip: Enable use_bar_magnifier for strategies where intrabar timing matters, but do not expect it to solve live venue latency. Bar Magnifier improves historical fill approximation; it cannot reproduce the order book dynamics or network delays you will face on a real exchange.
How to configure TradingView for more realistic backtests
A realistic backtest is not about making results look worse. It is about making them trustworthy. Follow this checklist before drawing any conclusions from a strategy report.
-
Set commission to match your broker. Use
commission_type=strategy.commission.percentand setcommission_valueto your actual rate. Most retail crypto and forex brokers charge modest commissions per side. -
Set slippage to a non-zero value. Even one or two ticks of slippage per order changes results materially for high-frequency strategies. Start conservative and test sensitivity.
-
Enable
backtest_fill_limits_assumptionfor any strategy that uses limit orders. Without it, the tester assumes limits fill the moment price touches them, which overstates fill rates. -
Enable
process_orders_on_closeonly when your live execution genuinely fires at bar close, such as with end-of-bar alert triggers. -
Enable
use_bar_magnifierwhen available on your plan. It will not eliminate intrabar blind spots, but it narrows them. -
Set
fill_orders_on_standard_ohlc=trueif your chart uses Heikin-Ashi candles. Heikin-Ashi prices are synthetic averages; filling orders on them produces fills that are impossible in live trading. -
Test across sufficient history. A larger number of completed trades in your backtest window generally produces more statistically meaningful results. Fewer trades mean the results are statistically fragile. Use TradingView’s Deep Backtesting feature (available on higher-tier plans) to extend your data range.
-
Avoid
request.security()lookahead. Usebarmerge.lookahead_offexplicitly and confirm that your multi-timeframe data references only confirmed bars.
Pro Tip: Keep a settings log. Document every strategy() parameter value alongside the strategy report export. When you revisit a strategy weeks later, you need to know exactly what configuration produced those results. Reproducibility is not optional if you plan to automate.
How do you detect repainting and lookahead bias in Pine Script?
Detection requires deliberate testing, not just visual inspection of the chart. Here is a reproducible protocol.
-
Swap lookahead flags and rerun. Change every
request.security()call fromlookahead=barmerge.lookahead_ontobarmerge.lookahead_off. If the strategy report changes significantly, you had future-data leakage. The performance difference is the size of the bias. -
Run bar replay and compare trade timestamps. TradingView’s bar replay mode steps through history bar by bar. Run your strategy in replay and note when each trade fires. Then compare those timestamps to the strategy report. Any trade in the report that appears before the bar where the signal logically could have formed is a lookahead artifact.
-
Force strict indexing in your code. Reference series values with explicit bar offsets (
close[1]instead ofclose) where you intend to use confirmed data. Then re-run and compare outputs. -
Run the four-step test protocol:
-
Freeze all inputs and parameters.
-
Run bar replay across a representative sample of your backtest period.
-
Export the strategy report and compare trade entry times and prices against the replay log.
-
Flag any trade where the entry price or timestamp is impossible given the bar’s OHLC data at decision time.
-
A strategy that passes this protocol is not guaranteed to be profitable. It is guaranteed to be honest about what it would have done.
Validation and forward-testing best practices
A backtest is a hypothesis. Forward testing is the experiment. The pipeline below moves you from one to the other without betting real capital on an untested assumption.
-
Confirm no lookahead. Run the detection protocol above. Do not proceed until the strategy is clean.
-
Run a realistic-cost backtest. Apply broker-like commission and slippage. Record the full strategy report including max drawdown, Sharpe ratio, and profit factor.
-
Run an out-of-sample test. Reserve the most recent 20–30% of your data as a holdout period. Optimize parameters only on the in-sample window, then run the strategy unchanged on the holdout. A strategy that degrades severely on out-of-sample data is overfit.
-
Apply walk-forward testing. Divide your history into rolling windows. Optimize on each training window and test on the following period. Consistent performance across windows is a stronger signal than a single in-sample result.
-
Run Monte Carlo resampling. Randomly resample your trade sequence and slippage scenarios to estimate the range of outcomes your strategy might produce. This gives you a realistic drawdown distribution rather than a single equity curve.
-
Paper trade for at least 4–8 weeks. Use TradingView’s paper trading account or a simulated execution environment. Monitor fill rates, slippage deviation, and behavioral divergence from the backtest.
-
Small live rollout with monitoring. Start with minimal position sizes. Track slippage per trade, fill rate, alert latency, and any behavioral divergence from the paper-trade period. Set a rollback threshold: if live drawdown exceeds paper-trade drawdown by more than a defined percentage, pause and investigate.
Walk-forward testing combined with Monte Carlo resampling provides a practical robustness check when full tick data or a professional-grade simulator is unavailable.
Execution and automation caveats for live Pine Script strategies
Moving from a validated backtest to a live automated strategy introduces a new category of operational risk that the Strategy Tester cannot model at all.
-
Alert latency. TradingView fires alerts when a bar closes or a condition is met. The time between that event and your bot receiving the webhook can range from milliseconds to several seconds, depending on server load and network conditions.
-
Webhook processing time. Your automation platform must parse the alert, validate it, and send an API order to the exchange. Each step adds latency.
-
Partial fills and rejections. The tester assumes full fills at the specified price. Live markets fill orders partially when liquidity is insufficient, and exchanges reject orders for margin, balance, or format reasons.
-
Position reconciliation. If an alert is missed or a fill is partial, your bot’s assumed position diverges from the actual exchange position. Without reconciliation logic, subsequent orders compound the error.
Even with calc_on_every_tick and Bar Magnifier enabled, these operational realities are outside the tester’s scope. Automation platforms must gate fills, confirm order status, and handle exceptions explicitly.
Pro Tip: Build a real-time alert-to-execution audit log from day one. Log every alert received, every API call made, and every fill confirmed. During early live testing, keep a manual fallback path: know exactly how to flatten your position manually if the bot behaves unexpectedly.
For a practical walkthrough of connecting TradingView alerts to live execution, the guide on how to automate trading on TradingView covers the full alert-to-bot pipeline.
Developer checklist: code and tests to harden a Pine Script strategy
Copy this checklist into your repository README before any deployment.
Code checklist:
-
[ ]
strategy()is called exactly once, unconditionally, at the top of the script. A conditional or missingstrategy()call compiles the script as an indicator and disables order simulation. -
[ ] All
request.security()calls usebarmerge.lookahead_offexplicitly. -
[ ]
slippageandcommission_type/commission_valueare set to non-zero, broker-like values. -
[ ]
backtest_fill_limits_assumptionis set for any limit-order logic. -
[ ]
fill_orders_on_standard_ohlc=trueis set if the chart uses Heikin-Ashi candles. -
[ ] Position sizing uses
default_qty_typeanddefault_qty_valueexplicitly rather than relying on defaults. -
[ ] Series references use explicit bar offsets (
[1]) wherever confirmed-bar data is required.
Testing checklist:
- [ ] Bar-replay comparison completed: trade timestamps match strategy report.
-
[ ] Lookahead swap test completed: results stable after switching to
barmerge.lookahead_off. - [ ] Out-of-sample window tested: holdout period performance documented.
- [ ] Strategy report exported and archived with full parameter settings.
- [ ] Monte Carlo resampling run: drawdown distribution reviewed.
- [ ] Sample size confirmed: at least 50–100 completed trades in the backtest window.
Why intrabar order fill modeling is harder than it looks
The intrabar fill problem is more subtle than most traders realize, and it affects fill accuracy in ways that compound across a strategy’s trade history.
When a historical bar closes, the tester knows four prices: open, high, low, and close. It does not know the order in which those prices occurred. For a bar with a wide range, this ambiguity is significant. If your stop loss sits between the bar’s open and its low, the tester will trigger the stop, but it cannot know whether price reached the stop before or after a potential take-profit level. It uses a fixed assumption: high comes before low in a bullish bar, low before high in a bearish bar. That assumption is wrong a meaningful portion of the time.
Enabling calc_on_order_fills helps by recalculating the strategy at up to four points per historical bar (open, high, low, close), which narrows the ambiguity. But it does not resolve it. The sequence of intrabar prices is still unknown. For strategies where the difference between a stop and a target being hit first materially changes the outcome, this limitation can skew results in either direction.
Bar Magnifier addresses this by pulling in lower-timeframe data. On a 1-hour chart with Bar Magnifier enabled, the tester uses 1-minute or 5-minute bars to approximate the intrabar price path. This is a genuine improvement. But it still cannot simulate prices that never appeared in the historical feed, and it cannot model the order book dynamics that determine whether your order would have been filled at the bid, the ask, or somewhere in between.
For scalping strategies or any approach where intrabar timing is the core edge, these limitations are not minor. They are structural. The TradingView Strategy Tester is honest about this in its documentation: historical bars lack tick-by-tick updates, and strategies are calculated once per historical bar by default.
A workflow to systematically identify and mitigate backtest biases
Bias identification should be a structured process, not an afterthought. This workflow applies to any Pine Script strategy before deployment.
Phase 1: Data and code audit
-
Confirm the data source. Is it adjusted for splits and dividends? Does it include survivorship bias (delisted assets)?
-
Audit every external data call. Document each
request.security()call, its timeframe, and its lookahead setting. -
Check for repainting indicators in your signal logic. If an indicator recalculates historical values, note it.
Phase 2: Cost and execution audit
-
Apply realistic commission and slippage. Compare the strategy report before and after. The delta is your cost sensitivity.
-
Test
backtest_fill_limits_assumptionvalues of 1, 3, and 5 bars for limit-order strategies. Observe how fill rate and performance change.
Phase 3: Statistical audit
-
Count completed trades. Below 50, results are anecdotal. Below 100, treat them as directional only.
-
Check for parameter sensitivity. Shift each optimized parameter by 10–20% and observe the performance change. A strategy that degrades sharply on small parameter shifts is overfit.
-
Run the out-of-sample test. Reserve recent data and test without re-optimizing.
Phase 4: Behavioral audit
-
Run bar replay across at least 20 representative trades. Confirm each trade’s entry and exit match the strategy report.
-
Compare paper-trade results to backtest expectations over 4–8 weeks.
How TradingView’s strategy tester compares to professional-grade platforms
TradingView’s Strategy Tester is accessible, fast, and deeply integrated with Pine Script. For most retail traders and algorithmic developers, it is the right starting point. But understanding where it sits relative to professional tools helps you calibrate how much weight to put on its results.
What TradingView does well:
-
Tight integration with Pine Script means no data export or format conversion.
-
Bar Magnifier and Deep Backtesting (on paid plans) extend intrabar and historical fidelity meaningfully.
-
The strategy report provides net profit, max drawdown, Sharpe ratio, and trade-level detail without additional tooling.
-
Paper trading is built in, making the backtest-to-forward-test transition frictionless.
Where professional platforms differ:
Professional backtesting environments, including those used by institutional desks, typically operate on tick-level data with full order book depth. They can simulate partial fills based on available liquidity at each price level, model queue position for limit orders, and replay exchange microstructure. They also support multi-asset, multi-venue strategies with cross-margin modeling.
TradingView cannot model order book depth, partial fills based on liquidity, or exchange microstructure. Even with tick-level data enabled, historical data cannot reproduce exchange microstructure like order book depth, partial fills, and latency. For high-frequency or liquidity-sensitive strategies, external tick data and venue-grade simulators are necessary.
For the majority of swing, trend-following, and daily-bar strategies, TradingView’s tester with realistic cost settings is sufficient to generate a meaningful hypothesis. The gap between TradingView and professional platforms matters most for strategies where execution quality, intrabar timing, or market impact are central to the edge. If your strategy trades once per day on liquid instruments, the tester’s limitations are manageable. If it scalps on 1-minute bars with tight stops, the limitations are load-bearing.
The practical takeaway: use TradingView’s tester to filter and develop strategies, then validate the survivors with forward testing before committing capital. For a deeper look at how Pine Script indicators affect execution timing for scalpers, the execution timing differences between indicators and strategies are worth reviewing before building a short-timeframe system.
How do order-fill assumptions affect limit orders and Heikin-Ashi charts?
Order-fill assumptions are where many traders discover their backtest was more fiction than forecast.
Market orders vs. limit orders
For market orders, the tester fills at the next bar’s open by default. This is a reasonable approximation for liquid instruments on daily or hourly charts. For limit orders, the default assumption is that the order fills the moment price touches the limit level. In live trading, a limit order fills only when there is a counterparty willing to trade at that price, and queue position determines whether your order is filled before the market moves away.
The backtest_fill_limits_assumption parameter addresses this by requiring price to remain at or beyond the limit level for a specified number of bars before the fill is confirmed. Setting this to 1 or more bars is a more conservative and realistic assumption for most limit-order strategies.
Heikin-Ashi fill distortion
Heikin-Ashi candles are calculated as averages of OHLC data. Their open, high, low, and close values do not correspond to any actual traded price. If you run a strategy on a Heikin-Ashi chart without setting fill_orders_on_standard_ohlc=true, the tester fills orders at Heikin-Ashi prices that never existed in the market. The strategy properties documentation explicitly covers this setting. Always enable it when your chart uses Heikin-Ashi candles.
How do you move from backtest to live trading reliably?
The backtest-to-live transition is where most strategies fail, not because the strategy is wrong, but because the validation process was incomplete.
The most reliable path combines three stages: a clean, realistic-cost backtest; a structured forward test; and a monitored small-scale live rollout. Each stage answers a different question. The backtest asks whether the logic has ever worked. The forward test asks whether it works on data the strategy has never seen. The live rollout asks whether it works when real execution costs, latency, and market impact are in play.
Sensitivity analysis belongs in the backtest stage. If performance collapses on small changes, the strategy is fragile. A robust strategy degrades gracefully as parameters move away from their optimized values.
During the live pilot, monitor four metrics: slippage per trade versus the backtest assumption, fill rate for limit orders, alert-to-execution latency, and any behavioral divergence from the paper-trade period. Set explicit thresholds. If live slippage consistently exceeds your backtest assumption by more than a defined amount, or if fill rate drops below a defined level, pause the strategy and investigate before scaling up. For practical guidance on effective backtesting and validation methods, including walk-forward and out-of-sample approaches, that resource covers the full validation pipeline for retail traders.
Common pitfalls when interpreting strategy tester results
Even a well-configured backtest can mislead you if you misread the output.
Confusing gross profit with net profit. The strategy report shows both. Gross profit ignores commission and slippage. Always evaluate net profit after costs.
Treating max drawdown as the worst case. Historical max drawdown is the worst drawdown that occurred in your test period. Future drawdowns can and often do exceed it. Monte Carlo resampling gives you a distribution of possible drawdowns, which is more informative than a single historical figure.
The same win rate on 200 trades is worth examining. Always check sample size before drawing conclusions.
Assuming the backtest period is representative. A strategy tested only on a bull market will look different in a range-bound or bear market. Test across multiple market regimes if your data allows.
Misreading the equity curve. A smooth, upward equity curve looks reassuring. But if it was produced by a small number of large winning trades, the strategy’s real-world behavior may be lumpy and psychologically difficult to hold through drawdowns.
The Strategy Tester is a hypothesis generator, not a performance guarantee. Treat its output as the starting point for a validation process, not the conclusion.
From backtest to bot: how Tickerly bridges the gap
Once your strategy passes the validation pipeline, the next challenge is execution. TradingView fires alerts; it does not execute orders. Connecting those alerts to a live exchange requires an automation layer that handles webhook parsing, API order submission, fill confirmation, and position reconciliation.
Tickerly converts your TradingView strategy alerts into fully functional trading bots with no-code setup, ultra-fast execution, and support for crypto, forex, stocks, futures, and prop firm markets. It connects directly to exchange APIs, handles multi-strategy and multi-asset configurations simultaneously, and provides real-time alert logging so you can audit every alert-to-execution cycle. For traders who have done the work of validating a Pine Script strategy and are ready to automate, Tickerly’s automated bot platform removes the operational friction between a validated backtest and a live, running strategy.
The backtest tells you what happened, not what will happen
Most traders treat a strong backtest as evidence that a strategy works. It is not. It is evidence that the strategy would have worked on that specific dataset, under those specific assumptions, with that specific parameter set. The distinction matters enormously when real capital is at stake.
The conventional advice on Pine Script backtesting focuses heavily on settings: add slippage, add commission, enable Bar Magnifier. That advice is correct, but it addresses only the configuration layer. The deeper issue is epistemological. A backtest is a model, and every model has assumptions baked in that the real world does not share. The bar-close model assumes you can always fill at the next open. The OHLC assumption assumes you know the intrabar price path. The zero-cost default assumes markets are frictionless. None of these are true.
What actually matters first is not the settings. It is the question you are asking. A backtest should answer: “Does this logic have a structural edge, or am I fitting noise?” If the answer is yes after realistic costs and out-of-sample testing, then the settings refinements are worth pursuing. If the answer is no, better settings will not save it.
The second thing most traders underestimate is the forward-test gap. The period between a clean backtest and a confident live deployment should be measured in weeks, not hours. Paper trading feels slow and anticlimactic after a backtest that shows strong results. That discomfort is the point. A strategy that holds up through 4–8 weeks of paper trading, with fill rates and slippage close to backtest assumptions, has earned a small live allocation. One that has not been forward-tested has not.
Treat the Strategy Tester as a filter, not a verdict. It is the first gate, not the last.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
FAQ
What are the main limitations of Pine Script’s strategy tester?
The Strategy Tester runs on a bar-close model by default, filling market orders at the next bar’s open and using no intrabar tick data. It also defaults to zero slippage and commission, which consistently overstates performance.
Can TradingView’s backtesting replace forward testing?
No. The tester cannot model alert latency, partial fills, order book depth, or live exchange behavior. Forward testing on a paper account for at least 4–8 weeks is required before live deployment.
What causes lookahead bias in Pine Script strategies?
Using request.security() with barmerge.lookahead_on is the most common cause. It allows the strategy to read a higher-timeframe bar’s closing price before that bar has actually closed, leaking future data into the backtest.
What are the limitations of TradingView as a platform for backtesting?
TradingView’s tester lacks tick-level order book data, cannot model partial fills or queue position for limit orders, and restricts features like Bar Magnifier and Deep Backtesting to paid plans. It is well-suited for hypothesis generation but not for microstructure-sensitive strategies.
How many trades does a Pine Script backtest need to be statistically valid?
Aim for a sufficiently large number of completed trades in your backtest window to ensure statistical validity. Fewer trades make results statistically fragile, and parameter optimization on small samples almost always produces overfit results.