Schirp's list of preconditions a test suite must satisfy before mutation testing is useful: (1) green tests — mutation engines derive signal from initially-passing tests, else they emit a no-op error; (2) idempotent tests — mutation runs the suite many times (e.g. 10 operators × 10 selected tests = 100 executions); non-repeatable I/O or shared resources break this; (3) randomized-order-runnable — the engine picks arbitrary subsets and orders, so tests that depend on implicit sequence (test A creating an artifact test B reads) fail; (4) concurrency-hard — mutation testing parallelizes trivially, so shared external I/O resources (e.g. a DB) must be managed; (5) selection metadata — RSpec describe/context metadata or explicit coverage declarations must let the engine pick the right subset of tests per subject; (6) discoverable subjects — all candidates must be loadable upfront. Rails challenges most of these (auto-loads hide subjects, shared DB state breaks idempotency/order, concurrency against the DB is hard).