Backtest Before You Trade Live
Why backtest at all
The exercise earns its place for three reasons, none of which is proving that a method makes money.
Being clear about what you are trying to learn keeps the test honest, because most of the ways a backtest goes wrong come from asking it for a verdict it cannot give.
Checking rule viability
The first thing a test reveals is whether your rules are complete. Applying them bar by bar to a stretch of chart quickly exposes the moments where the page does not say what to do, and those gaps are the real output. A rule set that cannot be applied without live judgement is not finished, and there is no cheaper way to discover that.
Building confidence
Seeing your setup appear repeatedly across a period gives you a realistic sense of how often it fires, what a normal losing sequence looks like, and how long you will be waiting between opportunities. That familiarity helps when the same sequence happens live, because it arrives as something recognised rather than as evidence that the method has broken.
There is one more benefit that only appears afterwards. A test creates a written record of what your rules produced across a defined stretch, which gives you something to compare your live results against. Without it, a disappointing live month has nothing to be measured against and tends to be interpreted as failure. With it, you can at least ask whether the live sequence looks like the ones the test contained, which is a much more answerable question.
Removing guesswork
A tested rule set replaces the question "does this work" with the narrower question "did this fire, and what happened". The second is answerable. The first is not, and traders who insist on it end up adjusting rules until the answer looks like yes, which is the failure described later on this page.
- Completeness first. Gaps in the rules are the main finding.
- Frequency second. How often it fires shapes everything else.
- A verdict is not available. No test produces one honestly.
Backtest to find gaps in your rules and to learn how often they fire, not to obtain a verdict.
Test with honesty
The dishonesty in backtesting is structural rather than deliberate: you know what happened next, and that knowledge leaks in unless the process prevents it.
Three practices remove most of the leakage, and none of them require software.
Adequate sample
Enough occurrences that a run in either direction cannot explain the outcome. How many that is depends on how often your rules fire; a setup appearing twice a week needs a long period to produce a usable count. If gathering the sample takes months, that is information about the rule set rather than a problem to be solved by shortening the test.
Out-of-sample data
Develop the rules on one period, freeze them, and apply them unchanged to a period you did not look at while developing. This is the step that separates a discovery from a description, and it is the step almost always skipped because the result is frequently disappointing. A rule set that performs on the development period and not on the untouched one has been shaped to fit history.
Realistic assumptions
- Move bar by bar, left to right. Cover the chart to the right of your current position.
- Record ambiguous cases as taken. In real time you would have taken them.
- Count the setups you would have missed. Asleep, at work, away from the screen.
- Apply the payout arithmetic. A hit count means nothing without it.
- Log every occurrence, not only the interesting ones.
The second item is the one that costs the most apparent performance, and it is the one most worth keeping. Historical testing resolves every borderline case in the method's favour by default, because the outcome is visible. Deciding in advance that ambiguity counts as a trade removes that bias and usually removes a good part of the flattering result with it.
Bar by bar with the future covered, ambiguity counted as taken, and a frozen run on data you did not develop on.
Avoid curve-fitting
Curve-fitting is what happens when a rule set is improved against history until it describes that history rather than anything durable.
It rarely feels like cheating. It feels like refinement, and each individual adjustment has a plausible justification at the time.
Too many rules
Every added condition reduces how often the full set aligns, which shrinks your sample and increases the chance that what remains is a description of a particular stretch. A rule set that grows after every disappointing test is being fitted, and the growth is the symptom rather than the fix.
Over-optimised results
Oddly specific parameter values are the visible tell: a lookback of exactly nineteen, a threshold at a precise fraction. Values arrived at by tuning are values chosen because they worked on the sample, and there is no reason for the market to respect them afterwards. Round, unfussy numbers are a reasonable default and they degrade more gracefully.
The same check applies to the period rather than only to the parameters. Split your test stretch in half and look at each half separately. If the result comes almost entirely from one half, you have found a rule set that suited a particular market rather than one that describes a behaviour. That is not necessarily fatal, and it does tell you what conditions to watch for before trusting it live.
Fragile systems
A useful robustness check costs nothing: nudge each parameter slightly and re-run. If a small change collapses the result, the rule set was balanced on a particular arrangement of history rather than describing a real behaviour. A rule set worth keeping produces broadly similar outcomes across a band of nearby values.
| Sign | What it usually means |
|---|---|
| Conditions added after each poor test | Fitting to the sample |
| Precise, unusual parameter values | Tuned rather than reasoned |
| Result collapses on a small parameter change | Fragile; not describing a real behaviour |
| Rules cannot be justified without the results | Memorisation, not method |
Nudge every parameter and re-run. A result that collapses was fitted to history rather than found in it.
Know the limits
A test describes what already happened under conditions that may no longer apply, and no amount of rigour changes that.
The limits below are not defects in your method. They are properties of testing anything against the past.
Past is not future
The clearest way to hold this: your result tells you the rules matched a stretch of history. Whether the behaviour behind that match persists is a separate question, unanswerable in advance, and it is why review schedules and stop conditions exist. Nothing about a good test removes the need for either.
Regime changes
Markets shift between trending and ranging conditions, participation changes, and volatility regimes come and go. A rule set tested across a period containing only one condition has been tested against one condition, however long that period was. Testing across a stretch that visibly contains more than one is worth the extra effort and often changes the picture considerably.
Data quality deserves a brief mention as well. Charts from different sources do not always agree exactly, especially on short horizons, and instruments whose pricing is quoted rather than exchange-traded carry an additional unknown because no methodology is published for them. None of this makes testing pointless; it means a result that depends on precise levels or exact candle shapes is resting on something less solid than it appears.
Live execution gaps
The gap between test and live comes from things a test cannot contain: the moment of hesitation, the setup you missed because you were elsewhere, the trade you took that was not quite the setup. All of these are behavioural, none of them appear in a historical run, and together they usually account for more of the difference than any market change does. This is why forward-testing on the practice account matters at least as much as the historical run: you can forward-test the frozen rules on virtual funds and find out how the same rules behave when you are the one applying them.
A test says the rules matched some history. Forward-testing says whether you can apply them.
Backtest takeaways
The exercise is worth the time when it is asked the right question and misleading when it is asked the wrong one.
Test before risking money
Running your rules across past data, honestly, before any money is involved will tell you whether the rules are complete, how often they fire and what a normal losing stretch looks like. All three of those are worth knowing in advance, and all three are cheaper to learn on a chart than on a balance.
Stay honest
The honesty is procedural rather than moral: cover the chart, count ambiguity as taken, freeze the rules before running the untouched period, and record every occurrence. Each of these removes a specific way the result flatters you, and each of them costs apparent performance, which is exactly why they work.
- Frozen rules on untouched data. The only part of the test that carries information.
- Round parameters, few conditions. Fitting is visible in precision.
- Robustness check. Nudge and re-run before trusting anything.
- Forward test afterwards. The behavioural question needs a forward answer.
No test guarantees profit
No figures appear here, because this desk has backtested nothing and holds no account. What can be said structurally is that a historical result is a statement about the past and a claim about the future only by assumption, and that the assumption is exactly what review schedules and stop conditions are for. Treat a test as one input, forward-test what survives it, and let your own live record be the thing that decides.
A test narrows the field. Your forward record decides, and nothing else honestly can.
What readers ask about this setup
How do I backtest without a special tool?
Open a chart, scroll back to a starting point, cover everything to the right of it, and move forward one candle at a time applying your written rules. Record every occurrence including the ambiguous ones. It is slow and it is honest, and the slowness is what stops you from unconsciously using information the market had not produced yet.
What is out-of-sample testing?
You develop the rules on one period, then freeze them and apply them unchanged to a different period you never examined while developing. It matters because any rule set can be improved indefinitely against the history it was shaped on, so the untouched period is the only part of the exercise carrying information. It is also the step most often skipped, because the result is frequently disappointing.
How much data do I need for a meaningful test?
Enough occurrences that a run in either direction cannot explain the outcome, which depends entirely on how often your rules fire. A setup appearing twice a week needs a long period to produce a usable count. If gathering the sample takes months, treat that as information about the rule set rather than as a reason to shorten the test.
Why do backtested strategies fail live?
Usually for behavioural reasons rather than market ones. A historical run contains none of the hesitation, none of the setups you missed while away from the screen, and none of the trades that were nearly your setup. It also cannot include a change in conditions after the test period. Forward-testing the frozen rules on a practice account is what surfaces the behavioural half.