Write the rule as something you can observe
Before testing, define the input data (a quote, for example), the trigger, the resulting instruction, and the expected state. Include what should happen if data is delayed, the broker rejects the order, or only part of it fills.
“Close when the level is touched” leaves questions open. Is the level measured against bid, ask, last trade, or a theoretical value? Is the resulting order limit or market? Is the condition checked on every tick or at intervals? Those details affect the outcome and belong in the tool’s documentation.
A stop is an instruction, not a price guarantee
Stop and stop-limit orders behave differently. As Investor.gov explains, a triggered stop can become a market order, while a stop-limit may never fill if the market moves past its limit. Availability and exact policy vary by broker.
For options, include wide spreads, thin liquidity, and stale quotes in your tests. If an exit depends on external software, also document what protection remains at the broker when that software loses its connection.
Minimum cases for a review
- The price crosses the level and quickly reverses.
- An order is accepted but never fills.
- Only some contracts fill.
- A quote is delayed or the connection drops.
- A person changes the exit while an order is pending.
- The position is closed outside the application.
Record the state you observed in each case. Finding a condition that needs human intervention is more useful than counting only successful trades.
Include the cost of exiting
Net results depend on entry and exit prices plus applicable commissions and fees. On a small trade, omitting those costs can turn a modest gross gain into a net loss. Keep gross and net results separate and note the source of each cost.