XAGUSD EA: unit-testing the order-send wrapper before going live

[FXS London Scalper]

Building a small silver scalping EA, I learned the hard way that the trading logic is often fine while the order-sending code fails in ways the backtester never shows.

So before anything goes live I now test the order wrapper on its own, separately from the strategy. The wrapper is one function that takes direction, volume, stop, target and returns a result code.

Tests I run on a demo account:

• Volume normalisation: does 0.013 become 0.01 (or rejected) according to the symbol's volume step?
• Stop and target too close: does it respect the stops level, adjust, or refuse cleanly?
• Price normalisation to tick size. Silver has its own digits.
• Requote and off-quotes: does it retry with a fresh price, and how many times?
• Market closed: does it log and stop, or loop endlessly?
• Insufficient margin: does it reduce size or abort?

For each case I force the condition, for example by setting the stop closer than the stops level on purpose, and check the log output.

It took an afternoon. It also caught two bugs: a rounding error that produced invalid stop prices on XAGUSD, and a retry loop that would have spammed the server.

Does anyone use a proper testing framework for MQL5, or is everyone doing manual demo tests like me?

[Shadow Trader]

Many tick feeds record time to the second only. When ten ticks share the same timestamp, the order in which they happened is lost, or at least ambiguous.

For a scalper, that matters. Whether the stop or the target was hit first, whether the spike went up before down, whether a signal fired before or after a reversal, all depend on order. A file with second-level timestamps can't answer.

Millisecond data solves most of that. Even then, some feeds batch updates and stamp them with the same millisecond, which hides the real sequence again.

When backtesting a strategy with targets of 2 or 3 pips, checking the timestamp resolution of the source is the first step. A source with second resolution can't be trusted for sub-minute logic.

Also check whether ticks arrive in order. Network delays can produce a file with a later timestamp preceding an earlier one. Sorting before testing avoids odd results.

What timestamp resolution does the tick source used here provide, and has the ordering ever caused a surprise?