Can historical profitable trades be used as the test table?
They can provide input examples, but expected software behaviour should be separated from profit. Historical outcomes do not establish future performance or prove every rule boundary.
Trading Systems
Turning Trading Strategy Rules Into a Test Table
Translate client-defined entry, exit, sizing, timing, and stop conditions into example rows that engineering and stakeholders can verify together.
How the workflow connects
- 1Define one decision point
- 2List required input values and timing
- 3Add boundary and missing-data rows
- 4Write the expected software action
- 5Review and version the approved examples
A strategy description may be understandable to its author and still leave several valid software interpretations. A test table makes those interpretations visible before implementation. It does not evaluate whether a strategy is financially sound; it confirms how client-defined rules should behave for specified inputs.
Choose one decision and freeze its inputs
Start with a single client-defined decision such as whether an entry request is eligible. List the instrument, timestamp, market session, indicator values, current position, pending orders, configured limits, and input freshness. Do not combine entry, sizing, and exit into one row if they can be reviewed separately.
Record the source and precision of each input. A value calculated from a closed bar may produce a different decision from the same indicator updated during an active bar.
Write examples around boundaries
Include values just below, equal to, and just above each threshold. Add session boundaries, zero or maximum position values, stale data, missing inputs, and an existing open order. These rows force the specification to state inclusive comparisons and precedence between rules.
- Input values and observation time
- Current account and order state
- Expected eligible or ineligible result
- Expected reason code
- Whether an order request may be created
Separate decisions from execution results
A rule test can expect that software creates a permitted order request. It should not expect that the broker fills at a particular price or that the trade makes money. Execution acceptance uses simulated broker responses to verify submitted parameters, state transitions, and error handling.
Version the table with the strategy rules
Give the rules and examples a version. When a threshold, timing assumption, or precedence rule changes, update the affected rows and retain the approved history. Automated tests can later encode the same examples while the table remains readable to non-developers.
Apply the table to one complete entry rule
Take a client-defined rule that permits an entry only during a specified session when two numeric conditions are true and no position is open. Freeze the timestamp, timezone, indicator inputs, current position state, permitted instrument, and configuration version. The expected result should state eligible or not eligible and identify the rule that decided it.
Use the rows to settle rule precedence as well as individual comparisons. Decide whether invalid or stale data is checked before session timing, whether a position guard takes precedence over numeric conditions, and which reason appears when more than one rule fails. The expected evidence should make that ordering visible in the decision record.
| Scenario | Session | Condition | Position | Expected software decision |
|---|---|---|---|---|
| Below threshold | Open | Value below configured boundary | None | Not eligible: threshold |
| At threshold | Open | Value equals boundary | None | Use documented inclusive rule |
| Position exists | Open | All numeric rules pass | Open | Not eligible: position guard |
| Input stale | Open | Last update exceeds freshness limit | None | Reject evaluation and alert |
| Strategy disabled | Open | All inputs valid | None | No execution request |
Connect test decisions to execution without conflating them
A rule table proves how the strategy decision should behave for known inputs. It does not prove that a broker will accept an order, that market data will arrive on time, or that a financial outcome will occur. Keep eligibility, order construction, broker submission, and later order state as separate test layers with their own evidence.
During acceptance review, compare the approved table version with the configuration and decision evidence produced by the software. If a result differs, keep the original example and record whether the rule, configuration, or implementation needs to change. This preserves a reviewable link between the agreed behaviour and the tested release.
Visual guide
Four different questions in the trading workflow
Separating the layers keeps a strategy decision from being mistaken for an execution result or performance claim.
- 1
Eligibility
Do the frozen inputs satisfy the documented client-defined rules?
- 2
Order construction
Are side, type, quantity, price, and identifiers valid?
- 3
Venue response
Did the broker accept, reject, or leave the result uncertain?
- 4
Lifecycle
What later open, partial, filled, cancelled, or reconciled state occurred?
Practical questions
Questions that often come up
Who should approve the expected decisions?
The client or authorized strategy owner defines and approves strategy intent. Engineering can identify ambiguity and implement the approved rules but should not invent trading decisions.
Continue exploring
Related projects and tutorials
Work with Sun Cluster
Planning a similar system for your organization?
Sun Cluster implements client-defined trading rules with testable behaviour, broker connections, controls, and private deployment.