Build
Testing your strategy
Before a strategy touches any market data, it has to prove itself against a fixed set of required tests. This page explains what each test is for in plain terms, how to run the suite, and why the Preview and Backtest buttons stay locked until it is green.
Why tests come first
A backtest can only tell you about your idea if the code faithfully implements the idea. The required tests are how you (and the platform) know it does: they pin down the strategy's behavior on small, hand-crafted data windows where the right answer is known. They also encode the failure modes that quietly ruin backtests — looking ahead, mishandling session boundaries, resolving an ambiguous bar optimistically — so that a strategy which cheats, even accidentally, fails loudly before it produces a single misleading statistic.
The twelve required test cases
Every strategy workspace ships with a test file that names twelve required cases — the test taxonomy. They start as deliberate failures (“write me” stubs); your job is to make each one real. In plain terms:
| Case | What it proves |
|---|---|
unit | Your pure helper functions compute what you think they compute. |
synthetic_fixtures | You built the small synthetic data windows the other tests replay. |
positive_setup | A data window that must produce your setup… does. |
negative_setup | A near-miss window that must not produce a setup… doesn't. This is the test that keeps your pattern from matching everything. |
no_lookahead | Reading future data raises the lookahead alarm, and your decisions don't change when future rows are removed — the strategy genuinely doesn't peek. |
session_cutoff | A setup that appears too late in the session is not traded. |
stop_first | When a single bar touches both your stop and your target, the trade resolves stop-first — the pessimistic reading. |
target_first | A clean target-first path books the target correctly. |
missing_data | A gap in required data degrades safely — no crash, no fabricated values. |
chart_annotations_exist | Every setup draws something on the chart, so previews are always inspectable. |
data_quality_edge | A data-quality edge case (a bad tick, a daylight-saving day) is handled. |
roll_session_edge | A contract-roll or session-edge window is handled. |
Write the negative test with love
Most strategies fail in the market not because the pattern doesn't work but
because the code sees the pattern where it isn't. negative_setup —
the near-miss that must not trade — is where you encode that judgment.
Running the tests
- Cut a version first. Tests run against a specific version of your code, cut from the snapshot timeline. If you haven't cut one, the Run Tests button says so: “Cut a plugin version first.”
- Press Run Tests. The suite is queued (you'll see “Test suite queued”) and runs in an isolated environment against your saved code — the same code, byte for byte, that a later run would use.
- Read the results in the Tests panel. A summary line — e.g. “14 passed · 1 failed · 0 skipped · taxonomy INCOMPLETE” — sits above a per-case table with the case name, its taxonomy tag, the outcome, the duration and the failure message. “Taxonomy complete” means every one of the twelve required cases exists and ran.
Green means: all cases passed and the taxonomy is complete. A passing suite with a missing case is not green — a strategy can't skip the lookahead test just by deleting it.
Why Preview and Backtest unlock only when tests are green
The Preview and Backtest buttons are gated on the latest test results for the code version you're running. Until the suite is green, they are disabled, and the tooltip tells you exactly why:
- “Tests gate closed: no suite run recorded — Run Tests first.”
- “Tests gate closed: required taxonomy cases are missing.”
- “Tests gate closed: 2 failing case(s).”
The launch dialog repeats the gate with a status line — “Tests gate: green — 14 passed / 0 failed, taxonomy complete” — so you always know what the gate saw.
The reasoning: a preview or backtest of untested code produces numbers that look exactly like evidence but may just be bugs. The gate makes the cheap, fast check (seconds of tests on synthetic fixtures) a hard prerequisite for the expensive, persuasive one (minutes of running on market data). It's the same discipline a good quant team enforces socially — here it's built in.
Previews are slightly less locked than backtests
A tests-green version can run a bounded preview (a few sessions) right away. Full backtests additionally require the version to be explicitly approved — a deliberate human sign-off — before they can launch. The launch dialog explains the approval status whenever it blocks you.
When a test fails
- Read the Message column first — scaffolded stubs fail with a description of what you're supposed to build; real failures show the assertion that broke.
- Fix the code (or the test, if the test encoded the wrong expectation — you own both), save, cut a version and run again.
- Remember the suite runs your saved files — the autosave chip should read Saved before you run.