Should a forex automation infer missing strategy rules?
No. Engineering can identify ambiguity and provide implementation options, but the authorized client defines trading rules and acceptable operating behaviour.
Trading Systems
Turning Forex Entry and Exit Rules Into Automation Scenarios
Specify forex automation through timed examples covering quotes, spread, sessions, positions, orders, exits, and platform responses.
How the workflow connects
- 1Fix platform, symbol, and time context
- 2Provide indicator and quote inputs
- 3State current position and pending orders
- 4Apply entry, exit, and exclusion rules
- 5Record the expected platform request or no-action reason
Forex requirements often combine price conditions, candle timing, trading sessions, spread filters, position rules, and exit behaviour in one paragraph. Scenario tables separate those concerns and make platform assumptions visible before they become code. They verify software interpretation, not expected returns.
Fix the environment around each example
Record terminal or platform version, account mode, broker time zone, symbol, digits, point size, lot constraints, and whether the scenario uses tick, bar-open, or bar-close evaluation. Without that context, the same written threshold can be interpreted differently.
Separate eligibility from order construction
First decide whether the client-defined entry condition is eligible given session, spread, current position, pending orders, and data freshness. Then test quantity, order type, entry price, stop, target, expiration, and comment or identifier construction as a second decision.
- Evaluation time and source bar
- Bid, ask, spread, and indicator inputs
- Current positions and pending orders
- Eligibility result and reason
- Expected request parameters
Write exit and management cases independently
Add stop, target, time-based exit, opposite signal, trailing behaviour, partial close, and manual intervention cases only when they are part of the approved strategy. State whether logic applies per position, symbol, strategy identifier, or account.
Include platform rejection and restart behaviour
Simulate invalid volume, market closed, requote or price change, insufficient permission, connection loss, and terminal restart. Define whether the workflow retries, abandons, pauses, or asks for review. Preserve identifiers so restart recovery does not duplicate a request.
Work through one timed entry scenario
A test case should state the symbol mapping, broker server time, session window, price source, bid and ask values, spread rule, indicator inputs, account mode, existing position and order state, configuration version, and whether automated requests are enabled. The expected result describes software behaviour: no action, a rejected evaluation, or a specific order intent.
For a session boundary, test the instant before opening, the opening instant, the final permitted instant, and the instant after closing. Include daylight-saving changes and broker timezone differences where they affect the client-defined rule. Keep the intended timezone in configuration rather than assuming the computer's local clock.
| Scenario | Context | Expected software behaviour |
|---|---|---|
| Session not open | Valid inputs before configured start | No order intent; record session guard |
| Spread above limit | Signal true; current spread outside rule | Reject eligibility with observed spread |
| Existing position | Entry rules true; position already open | Apply documented position guard |
| Stale tick | Last price older than freshness boundary | Block evaluation and expose stale-data state |
| Platform reconnect | Prior request result uncertain | Reconcile before new submission |
Test the order lifecycle and restart path
Entry eligibility, order construction, position management, and exit behaviour need separate cases. A valid signal can still produce an invalid volume, unsupported filling policy, market-closed rejection, or requote. Capture the platform return code and source response, then map it to a named internal outcome without hiding the original evidence.
Restart tests should define how the automation discovers existing orders and positions, restores trailing or management state, and handles a configuration that changed while the platform was offline. When required information cannot be reconstructed safely, remain paused for review. Historical and demo checks can reveal implementation problems but cannot establish future results.
Visual guide
Scenario layers from rule to platform result
Each layer has different acceptance evidence and should be tested without treating a signal as a completed trade.
- 1
Rule inputs
Time, prices, spread, indicators, configuration, current exposure.
- 2
Eligibility
Client-defined entry, exit, and position-management decisions.
- 3
Order intent
Symbol, side, type, volume, price rules, and stable ID.
- 4
Platform response
Accepted, rejected, requoted, timed out, or unavailable.
- 5
Lifecycle and restart
Later state, reconciliation, and recovery evidence.
Practical questions
Questions that often come up
Do passing scenarios prove the strategy will perform?
No. They show that specified software behaviour matches approved examples. They do not predict or guarantee financial results.
Continue exploring
Related projects and tutorials
Work with Sun Cluster
Planning a similar system for your organization?
Sun Cluster implements client-defined forex and MT5 automation with test scenarios, demo verification, controls, and deployment handoff.