Backtesting is the practice of running an investment rule against historical prices to see what it would have done. It is the only way to test a systematic idea before risking money on it, and it is also one of the easiest ways to fool yourself, because a rule can be tuned until any history looks good. This section covers the practice from the ground up: how to run a backtest without writing code, what each number on the resulting tear sheet means, and the specific mistakes that make backtests lie.
What a backtest actually does
Strip away the software and a backtest is a loop. On each historical day, it looks at the information that would have been available that morning, applies the rule to decide what to hold, and records the return of that holding through the close. Chain the daily returns together and you have an equity curve. Summarize the curve and you have the metrics.
Every design decision in a backtesting system is about making that loop faithful to what would have actually happened. Using only information available at the time, so the rule does not see the future. Charging a transaction cost on every trade, because real trades are not free. Using total-return data, because dividends are part of what you would have earned. Starting the clock only when every asset in the universe existed, so the backtest is not quietly holding something that had not launched yet. ENSEMBLE's methodology page documents how the platform handles each of these.
How to backtest a portfolio without code
Historically, an honest backtest required either a programming language and a data subscription or a point-and-click tool that limited you to fixed allocations. The no-code walkthrough shows the third path: describe the portfolio in a sentence, and let the platform write and run the code.
The walkthrough builds a real portfolio step by step, from choosing a universe through reading the tear sheet, and explains what a good plain-language description contains. The short version is that a testable description names the assets, states how they are weighted, and says when the portfolio rebalances. "60 percent SPY and 40 percent TLT, rebalanced monthly" has all three. "A balanced portfolio" has none.
Reading a tear sheet
Backtest output is a dense page of numbers, and most of them are variations on four ideas. The metrics explained guide defines each one, shows how it is computed, and says what a reasonable range looks like for a diversified portfolio:
- Compound annual growth rate (CAGR) is the single yearly rate that would have turned the starting value into the ending value. It is the headline, and the least informative number on its own.
- Volatility is the annualized standard deviation of returns. It describes how bumpy the ride was, in both directions.
- Sharpe ratio is return in excess of a risk-free rate, divided by volatility. It tells you how much return you got per unit of risk.
- Maximum drawdown is the largest peak-to-trough decline. It is the number that decides whether you would have stayed invested.
The guide also covers the secondary figures that explain the primary ones: number of trades and turnover, which drive costs; time in market, which distinguishes a trend rule from a buy-and-hold rule; and the start and end dates, without which none of the other numbers can be compared to anything.
Where backtests go wrong
Most backtesting mistakes are not arithmetic errors. They are ways of letting information from the future leak into decisions that were supposed to be made in the past. The common mistakes guide covers the ones that matter most:
- Lookahead bias, where a rule uses a price or a data point that would not have been known at the time of the decision.
- Survivorship bias, where the universe only contains assets that still exist, so the backtest never holds the ones that failed.
- Overfitting, where parameters are tuned until the backtest looks good and the result describes noise rather than a repeatable pattern.
- Ignoring costs and taxes, which turns a high-turnover strategy that looks brilliant gross into one that loses to its benchmark net.
- Short samples, where a strategy is judged on a period that happens to contain only one kind of market.
Each mistake comes with a way to detect it and a way to avoid it, and the guide is honest about which ones no software can fully protect you from. Overfitting, in particular, is a discipline problem rather than a tooling problem.
Why plain language helps
It might seem that describing a strategy in a sentence is a shortcut that sacrifices rigor. In practice the opposite is often true. A sentence forces you to state the rule completely: if the description does not say when the portfolio rebalances, the platform has to ask, or pick a default and tell you what it picked. Code lets you leave that decision implicit in a loop somewhere and forget you made it.
Plain language also makes strategies comparable. When every model on ENSEMBLE begins as a prompt, you can read two prompts side by side and see exactly what differs between them, then read the two tear sheets and see what that difference did. That is the core of systematic research, and it is much harder to do with two scripts written by two people.
What to read first
If you have never run a backtest, start with the walkthrough. If you have a tear sheet in front of you and are unsure what a number means, go to metrics explained. If you have a backtest that looks too good, read common mistakes before you do anything else. And if you want to see what these ideas look like applied to specific rules, the strategies section works through dual momentum, risk parity, the 60/40 portfolio, and the 200-day moving average with live tear sheets for each.
ENSEMBLE is research software. Backtests are hypothetical, past performance does not guarantee future results, and nothing on these pages is investment advice.