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_py's own suite runs 267 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