Most software testing is satisfied by code that runs without an error. That bar is nowhere near strict enough for an execution engine, where the actual risk isn't a crash — it's code that runs cleanly, produces a plausible-looking number, and is subtly wrong about the price a trade actually filled at. Behavioral testing exists to catch that specific failure mode, which ordinary testing isn't built to look for.
What "behavioral" means here
A behavioral test doesn't just check that a function returns without throwing an exception. It sets up a specific, deliberate scenario — a limit order sitting exactly at a price the market is about to touch, a bracket with both sides in range on the same bar, a rejected order for insufficient margin — and checks the exact value the execution specification says should come out of it. Not "a reasonable-looking fill." The specific one the spec defines for that exact situation.
Why this needs to be exhaustive, not representative
A handful of typical-case tests can miss the scenarios where execution modeling actually goes wrong — the edge cases, not the common ones, are where an off-by-one in a fill calculation or an unhandled collision between two orders tends to hide. A real conformance suite has to work through the specification's own scenarios deliberately and completely: every order type, every time-in-force, every combination of bracket and collision, checked against its own defined outcome, not sampled at random and hoped to be representative of everything else. Reamer's own suite runs 282 such checks specifically for this reason — not because a large number is impressive on its own, but because that's roughly how many distinct scenarios the specification actually describes.
What passing actually proves
A test suite that passes isn't proof the engine is useful, profitable, or well-designed — it's proof that it does what the specification says it does, in every scenario the suite covers. That's a narrower, more specific claim than "the engine works," and it's a more useful one, because it's checkable by anyone willing to read the specification and the tests side by side, rather than resting on trust in whoever built it.
Full reference: docs · The specification this suite verifies conformance to: execution specification · The workflow this maps onto: reamerlabs.com