|
| 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