Test.Syd.Mutation.Forest

A trie over TestId paths, used for efficient filtering of a TestForest.

Build a TestIdTrie from a set of TestIds.

Build a TestIdTrie from a list of TestIds.

Flatten a TestForest into a list of '(TestId, value)' pairs.

TestIds are assigned by traversing the forest in order. Sibling nodes with the same description text receive a zero-based per-description index so that duplicate descriptions are still uniquely identified.

Like flattenTestForestWithIds, but pair each leaf TestId with the CallStack captured at its it/prop/specify call site (testDefCallStack) instead of the leaf value. The TestId assignment is identical, so the two stay in lockstep: a leaf's id here is the same id that the coverage phase records coverage against.

The CallStack lets the diff-scoped runner map a changed test-source line back to the tests defined there.

Filter a TestForest to only the tests present in the given TestIdTrie.

Wrapper nodes (setup, before-all, around-all, etc.) are kept whenever any of their children are kept.

Reorder a TestForest so that, at every sibling level, cheaper tests come first. A test's cost is its recorded baseline in the given map; a missing baseline counts as 0, so an untimed test runs first. A subtree is ordered by the minimum cost of any leaf it contains, so the group most likely to yield a cheap early kill runs first.

This is a drop-in alternative to execution-order randomisation, legal under exactly the same conditions. It mirrors randomiseTestForest: inside a DoNotRandomiseExecutionOrder scope it leaves the whole subtree as-is at every depth, and the caller only applies it when the suite's execution-order randomisation is enabled.

Only sibling order changes. Wrapper nodes keep wrapping their own children, so shared setup and teardown still run once per group and are never split. The sort is stable, so equal-cost siblings keep their source order.

TestIds are assigned with the same scheme as flattenTestForestWith, purely to look costs up; nothing downstream reads the ids of the reordered forest. When this runs on a forest that filterTestForestByTrie has thinned, the per-description sibling index of same-named siblings can shift relative to the baseline map's keys. That degrades ordering quality for same-named siblings only, never which tests run.

Decide the execution order for a mutation child's (already filtered) forest. Reorder cheapest-first with reorderTestForestByTiming only when the suite has execution-order randomisation enabled (so this stays a drop-in alternative to that randomisation) and a baseline is available; otherwise leave the forest untouched.

Kept pure and separate from the child's IO so the gate is testable: the child reads the baseline and looks up settingRandomiseExecutionOrder, then hands both here.