Automated Trading
Backtest a cTrader cBot
A backtest runs a cBot against historical data. Use it to check that the rules behave as intended and to examine the simulated outcome under recorded assumptions. It cannot establish future profitability.
An illustrative strategy
For this walkthrough, imagine a cBot that buys after a 20-period simple moving average crosses above a 50-period simple moving average on completed H1 bars. It closes that buy on the opposite crossover, allows one labelled position and uses a fixed, explicitly defined volume. This is a teaching example, not a recommended strategy or a claim of performance.
Your actual cBot must implement those rules before a test can examine them. Confirm whether it acts on a completed bar and whether it ignores historical signals at startup. A different interpretation can produce different trades even with the same average lengths.
Set up a reproducible test
- Use cTrader Windows or Mac. Build or install the cBot, select an instance and open Backtesting. Set the intended symbol, H1 period and strategy parameters.
- Choose explicit start and end dates. Include enough prior data for the slow average to initialise. Keep a separate period for later evaluation rather than choosing all settings from the same history.
- Open backtest settings and record the starting capital, commission rate, historical data source and spread assumptions supported by your version. Check commission units rather than entering a broker’s per-lot figure into a per-million field.
- Use suitable data detail. Tick data is useful when execution within bars matters; coarser bars can hide the sequence of price moves. Record whether the spread is fixed or random and the chosen value or range.
- Start the test. If no trades occur or the run stops, inspect the logs and warm-up data first. Save the settings and report alongside the source version so the test can be repeated.
Read the result as a set of trade-offs
Net profit is the simulated net outcome under the test’s cost assumptions. It is not a forecast. Check trade count alongside it: a result driven by very few trades gives little evidence about repeated behaviour. Look for a small number of unusually large trades dominating the total.
Drawdown describes a decline from a previous peak. Balance drawdown and equity drawdown measure different things because equity includes open profit or loss. Inspect the equity path as well as closed trades; a strategy can carry substantial unrealised losses before closing.
Inspect individual decisions
Use the trade history and, where useful, visual mode to inspect selected entries and exits. Compare the completed-bar crossover with the trade timestamp and check volume, costs and closing reason. Inspect both a trade that looks correct and a situation where the cBot stayed out.
If a trade appears early, establish which bar the code reads and when its event is called. If the volume or costs are unexpected, check the symbol specification and settings. A headline profit figure cannot identify those implementation errors.
Avoid fitting the answer to the past
Repeatedly changing average periods until one historical chart looks good can fit noise. Decide what you are testing before the run and keep a record of rejected variants. Check sensitivity to nearby parameter values and more demanding cost assumptions rather than celebrating a single best setting.
Use the held-back period without retuning to it. Compare different market conditions and note where the rules fail. Historical data, execution assumptions and unavailable external services can all limit what the simulation represents.
Follow up on demo
Run the same source and settings on a demo account and compare real-time decisions with the specification. Observe timing, rejected orders, restarts and connection interruptions that a historical test may not reproduce. A successful build, a completed backtest and a useful demo run are different checks; keep evidence for each.