Async Andy
“Parallel output order is a personality trait.”
How do we test ordering without trusting luck?
Elevator answer
Split one order into awkwardly numbered items, duplicate one, delay another, then prove the merge returns the promised count and order after retry. “Usually sorted” is not cardinality.
3 coffee-machine misconceptions
Test Terry
“One happy-path item proves fan-out.”
Kafka Frank
“Partition order solves every merge.”
The real explanation
One order becomes twelve line-item checks; item 7 retries, item 4 completes twice, and item 2 returns last. Does the merge emit twelve results, eleven, thirteen, or “whatever arrived”? Split and merge turn a tidy arrow into promises about count, lineage, duplicates, and order. Test the promises with hostile inputs.
TPF makes cardinality, linkage, and ordered step descriptors part of the contract. Tests should use deliberately awkward inputs: several branches, duplicate-like values, slow branches, rejection, and retries. Assert both values and lineage or ordering metadata. A test that only checks the final collection size can miss the bug that will confuse replay or downstream consumers.
The trade-off is more focused test cases. That is cheaper than treating nondeterminism as an operational characteristic discovered in production.
Trade-offs
TPF gains testable flow semantics. It gives up vague assumptions about concurrent order.
When TPF is not a good fit
If ordering is not a business requirement, do not impose it merely for prettier tests. State the weaker contract and scale accordingly.