I keep three kinds of results in separate folders: a fitted historical run, a historical holdout, and observations from a running terminal. They answer different questions. Combining them into one equity curve makes it harder to tell which assumptions survived contact with a period or an environment the EA had not seen.
Two different kinds of evidence
Backtesting applies a strategy's rules to historical market data. It is useful for checking whether the rules can be executed consistently and for exploring how the strategy reacted across a chosen historical sample. Forward testing runs the same rules over time without using later market information. It can reveal practical issues such as platform configuration, broker execution and changing market conditions.
Neither method is a forecast. Historical data cannot contain every future regime, and a forward period may be too short to represent a strategy's full range of behaviour. The strongest evaluation treats both as evidence with limitations, rather than choosing the result that looks best.
What to inspect in a backtest
Check the data source, date range, instruments, timeframe, modelling method, spread, commission, swap, execution delay assumptions and trade count. Ask whether the settings match the account you might use. A result based on unusually favourable costs or a narrow market period may not transfer well. Re-run results where possible, and be cautious about optimised parameter sets that have been repeatedly tuned to one period of history.
Do not confuse live observation with the tester's Forward setting
In this guide, forward testing means observing an unchanged configuration as new market data arrives. MetaTrader 5 also calls a later, held-out part of a historical test a Forward period. That is an out-of-sample historical check, not proof of a live deployment or real broker fills. Record which meaning a report uses before comparing it with a demo or live account.
What forward testing adds
A forward period exposes the strategy to an unfolding market and its operating setup. A demo account can reveal configuration, connectivity and sizing problems, but its simulated execution does not establish the fills a live broker would provide. A live account adds observations of actual execution and costs for that account and period. Neither a short positive period nor a short negative period establishes durability or a software defect by itself.
A practical comparison process
Use a written checklist: define the intended setup, compare test assumptions with real account conditions, review drawdown as well as return measures, and make no decision from one chart alone. If you later review a public track record, check what is verified, what dates are covered, and whether the evidence actually answers your question.
Make the comparison reproducible
Keep a short test record before interpreting the outcome:
- Version and inputs: Identify the exact EA and parameter set; label any later change as a new test revision.
- Periods: Record the development period and the later evaluation period, rather than calling a reused optimisation sample independent evidence.
- Account conditions: Record the symbol, account type, exposure and the cost/execution assumptions you can verify.
- Observations: Keep trade count, dates, losses, open exposure and journal issues alongside the headline result.
- Exceptions: Record missing information and explain why a comparison is incomplete instead of inventing a correction.
As a hypothetical process example, an operator freezes a configuration after reviewing historical data, then observes it through a later period. If the operator changes its inputs halfway through, the two forward segments are labelled separately. Combining them as one unchanged setup would hide a material difference. This example contains no SmiteFX test, measured return or universal minimum test length.
A demo forward period can help examine operation, but it does not establish the fills or costs a live account will receive. Similarly, profit factor is one result to interpret beside the sample and risk, not a pass mark. The platform's documented tester workflow and the observed account conditions must remain distinct.
Reconcile costs before comparing the curves
Keep the modelled spread, commission, financing and delay assumptions beside the observed account conditions. Compare the same instrument, account type, exposure and configuration. A difference between two reports is not automatically an unexplained strategy failure if their inputs differ. Use the spread and slippage guide to separate quoted costs from execution differences.
For a hypothetical audit, suppose a test assumes a constant spread while the later account records varying spreads and commission. Record that mismatch and reproduce the cost assumptions where the platform supports it; do not invent an adjustment that makes the curves agree. Check order timestamps, rejected requests and configuration changes before attributing a discrepancy to a single cause.
Match data granularity to the decision rules. If entries and exits depend on the order of movements inside a bar, a simplified bar model may not establish that sequence. The MQL5 testing reference documents modelling modes and their limitations. A detailed-looking report is not proof that its assumptions fit this EA.
Connect the evidence to an EA decision
Use the broader Expert Advisor evaluation checklist before allowing a system onto a live account. If the evidence includes a public account, our Myfxbook reading guide explains what to inspect at the source.
For SmiteFX product context, open the systems directory and review the relevant listing and source-account links. The procedure above is an editorial aid, not a claim about proprietary development rules. Testing cannot remove the risk of trading losses, and past results do not predict future performance.
Sources and further reading
The official MetaTrader 5 Strategy Tester documentation explains the platform testing workflow. The MQL5 documentation describes the broader automated-trading environment. These resources are technical references, not investment advice.
A simple tester-to-demo experiment
Use an invented example. Choose an EA preset using data through June, lock the inputs, and run the same preset on July and August without another optimisation. Then observe the unchanged version on a demo account in September. The date windows are illustrative. In a real study you would choose a trade sample and market conditions large enough for the decision at hand.
Log the signal time and reference price in the running terminal, then compare that record with the simulated entry rule. If there are fewer live observations, check whether that reflects the market, session settings, symbol suffix, rejected requests or an actual rule mismatch. Keep a separate record of investigations and version changes. A parameter change starts a new comparison instead of repairing the old record.
For a SmiteFX product reference, see Fortune MT5. Use the Market listing to identify the supported platform before collecting evidence. Save the exact test preset and terminal build for this EA, then use one version across the historical and demo stages so that you can trace any differences.
