Rails mutation-score rebaseline

12 October 2026 · Post-removal rebaseline: 9 of 10 selected Rails/RSpec targets complete. Chatwoot is pending.

ProjectMutation scoreMeasured scope
paper_trail81.3%record_trail / widget specs
alchemy_cms95.9%Attachment / attachment specs
fat_free_crm66.7%Account / accounts controller specs
doorkeeper89.5%Access-token and application mixins / model specs
administrate92.1%Field::Base / base field specs
solidus80.0%StockItem / stock-item specs
publify73.9%Four sidebars and Gravatar / six specs
mastodon74.3%Account / account specs
lobsters61.2%Story / story specs
chatwootPendingConversation / conversation specs; not included in the nine completed results

These are mutation scores for selected source files and their configured specs, not whole-app scores or a ranking of the projects. Higher scores mean the selected tests detected more of the tested changes. No-coverage work is excluded, so a high score does not establish broad coverage.

The post-removal engine is pinned to 1154806b6c66ef03826f8c137e9d9ad4b5616ae0, after the coarse-survivor gate was removed. These are measurements of that snapshot, not of every later release. Smaller eligible mutations now run even when a whole-body mutation survives. All nine rows used RSpec, seed 1, --jobs 2, harness v8.4 and POST_REMOVAL=1. Each app ran alone on its host. No multi-seed stability claim is made. Download counts, Ruby versions and exact app/engine pins (CSV).

Score = (killed + timeout) / (killed + survived + timeout). Assertion kills, crash kills and timeouts all contribute; errors, resource-limit stops and skips do not. A crash kill means changed code broke, not that a test asserted its return value. These completed runs had no tool errors or resource-limit stops. Mastodon has one per-mutant timeout, counted in its score.

Each result is a single complete run on a selected workload. The unchanged configured suites passed before mutation, and kills were checked against unchanged code. That does not prove flaky tests are absent. No speed or memory ranking follows from these scores, and different mutation sets make cross-version score comparisons limited.

Reading the scores

Assertion kill
A mutant made a test assertion fail and the unchanged code passed the check.
Crash kill
A mutant caused an exception or another recorded crash. It counts as detected, but is different evidence from an assertion.
Survivor
The selected tests passed. This may be a missing check, an equivalent change, flakiness or a tool limit; human review is needed.
No coverage
No selected test reached the edited code. It is skipped, not credited as a kill or counted as a survivor.
Timeout
The mutant exceeded its measured deadline. Current scoring counts it as detected; it is not an assertion kill.
Incomplete
Errors, resource-limit stops or no tested mutants mean the run cannot be called complete, even if a partial score exists.

Kill evidence by project

Counts, not a separate accuracy ranking. Timeouts are shown separately from assertion and crash kills.

ProjectTestedAssertion killsCrash killsTimeoutsSurvivors
paper_trail20960110039
alchemy_cms97514204
fat_free_crm391115013
doorkeeper390185164041
administrate101534008
solidus753921015
publify461816012
mastodon1837560147
lobsters8963082400348

Scope and caveats

Historical measurements

The earlier saboteur-versus-mutineer comparison and paired hashie fork-sharing experiment remain available in the archive. They are not a current competitor ranking. The competitor comparison rerun is separate and still pending; its pinned historical workload has not been changed.