Skip to content

Commit 7829df3

Browse files
committed
docs: running backtests
1 parent 56dec4c commit 7829df3

File tree

2 files changed

+107
-0
lines changed

2 files changed

+107
-0
lines changed

.vitepress/config.mts

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,12 @@ export default defineConfig({
4141
{ text: 'Multi-Series Custom Indicators', link: '/custom-indicator-multi-series' },
4242
{ text: 'Plotting Custom Indicators', link: '/custom-indicator-plotting' },
4343
]
44+
},
45+
{
46+
text: 'Backtesting',
47+
items: [
48+
{ text: 'Running a Backtest', link: '/running-backtests' },
49+
]
4450
}
4551
],
4652

running-backtests.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# Running a Backtest
2+
3+
Once you have created a strategy, the next step is to run it against historical data. Stochastix offers two primary methods for launching a backtest:
4+
5+
1. **Command-Line Interface (CLI):** Ideal for automation, scripting, and precise control over all configuration parameters.
6+
2. **User Interface (UI):** A web-based form that provides a user-friendly way to configure and launch backtests.
7+
8+
This guide will focus on the CLI method, as it exposes the full power and flexibility of the backtesting engine.
9+
10+
::: warning
11+
We're assuming Stochastix is installed using the Docker setup, which is the recommended way to run it. Therefore, we will use `make sf c="..."` to run commands in the Symfony container. If you're not using Docker, you can run the commands directly in your terminal using `php bin/console ...` instead.
12+
:::
13+
14+
## The `stochastix:backtesting` Command
15+
16+
The core command for running a backtest is `stochastix:backtesting` (alias: `stx:backtest`). At a minimum, it requires one argument: the `alias` of the strategy you want to test (as defined in its `#[AsStrategy]` attribute).
17+
18+
A basic execution looks like this:
19+
20+
```bash
21+
make sf c="stochastix:backtesting sample_strategy"
22+
```
23+
24+
When run like this, the backtest will use all the default values defined in your `config/packages/stochastix.yaml` file.
25+
26+
## Overriding Configuration at Runtime
27+
28+
The real power of the CLI comes from its ability to override any default configuration for a single run. This allows for rapid experimentation without constantly editing YAML files.
29+
30+
### Specifying a Timeframe and Date Range
31+
32+
You can control the resolution and time period of the data used in the backtest.
33+
34+
* `--timeframe` or `-t`: Sets the candle size (e.g., `5m`, `1h`, `1d`).
35+
* `--start-date` or `-S`: Sets the start date (`YYYY-MM-DD`).
36+
* `--end-date` or `-E`: Sets the end date (`YYYY-MM-DD`).
37+
38+
```bash
39+
# Run the strategy on a 4-hour timeframe for the year 2023
40+
make sf c="stochastix:backtesting sample_strategy -t 4h -S 2023-01-01 -E 2023-12-31"
41+
```
42+
43+
### Specifying Symbols
44+
45+
The `--symbol` (or `-s`) option lets you target specific trading pairs. You can use the option multiple times to run the backtest across several symbols in a single session.
46+
47+
```bash
48+
# Test the strategy on both BTC/USDT and ETH/USDT
49+
make sf c="stochastix:backtesting sample_strategy -s BTC/USDT -s ETH/USDT"
50+
```
51+
52+
### Overriding Strategy Inputs
53+
54+
You can change any parameter you defined with an `#[Input]` attribute in your strategy using the `--input` (or `-i`) option. The format is `-i key:value`.
55+
56+
```bash
57+
# Given a strategy with inputs 'emaFastPeriod' and 'emaSlowPeriod'
58+
59+
# Change the EMA periods for this specific run
60+
make sf c="stochastix:backtesting sample_strategy -i emaFastPeriod:10 -i emaSlowPeriod:30"
61+
```
62+
63+
### Overriding Global Configuration
64+
65+
For global settings like initial capital, you can use the `--config` (or `-c`) option.
66+
67+
```bash
68+
# Run the backtest with an initial capital of 50000
69+
make sf c="stochastix:backtesting sample_strategy -c initial_capital:50000"
70+
```
71+
72+
## Saving and Reusing Configurations
73+
74+
For complex experiments, you can save a complete configuration to a JSON file and reuse it later.
75+
76+
1. **Save a configuration:** Use the `--save-config` option. The command will resolve all other options and save the result to a file without running the backtest.
77+
78+
```bash
79+
make sf c="stochastix:backtesting sample_strategy -s SOL/USDT -i emaFastPeriod:5 --save-config=my_sol_test.json"
80+
```
81+
82+
2. **Load a configuration:** Use the `--load-config` option to run a backtest with the exact settings from a file.
83+
84+
```bash
85+
make sf c="stochastix:backtesting sample_strategy --load-config=my_sol_test.json"
86+
```
87+
Any other CLI options used alongside `--load-config` will override the values from the JSON file.
88+
89+
## Execution Model: Synchronous vs. Asynchronous
90+
91+
The way a backtest is executed depends on how you launch it.
92+
93+
### CLI Execution (Synchronous)
94+
95+
When you run the `stochastix:backtesting` command from your terminal, the process is **synchronous**. The command invokes the backtesting engine directly and will not exit until the entire backtest is complete. Once finished, it will print the results summary directly to your console. This blocking behavior is ideal for scripting and automated tasks where you need to wait for the result before proceeding.
96+
97+
### UI / API Execution (Asynchronous)
98+
99+
When you launch a backtest from the web interface, the process is **asynchronous**. The UI sends a request to the API, which creates a `RunBacktestMessage` and dispatches it onto a message queue, returning a "queued" status almost instantly.
100+
101+
A separate, long-running worker process (`messenger-worker` service in `compose.yaml`) is responsible for picking up this message from the queue and executing the backtest in the background. This prevents web server timeouts and allows the UI to track the progress of the run in real-time.

0 commit comments

Comments
 (0)