Bump simplecov from 0.22.0 to 1.2.0 in /backend

[dependabot]

Bumps simplecov from 0.22.0 to 1.2.0.

Release notes

Sourced from simplecov's releases.

v1.2.0

SimpleCov 1.2 adds change-focused coverage, per-test attribution, production coverage, and a substantially expanded CLI while keeping the existing configuration API working through deprecation aliases.

Highlights

• track_tests, simplecov tests, and simplecov affected connect covered lines to the tests that exercised them; the HTML report displays the same attribution and simplecov watch uses it for focused reruns.
• simplecov patch, per-file baselines, missed-count caps, and coverage history make coverage gates useful for both new changes and legacy codebases.
• SimpleCov::Production records low-overhead production line coverage, while simplecov dead-code and the bundled reports cross it with test coverage.
• ActionView templates can be measured with cover_views, including ERB, Haml, and Slim source highlighting.
• The CLI gains annotated source, report freshness, history, badges, shell completions, a man page, and richer machine-readable output.

Upgrade notes

• The minimum supported Ruby remains 3.2; JRuby 10 remains supported for line coverage.
• Successful runs now maintain the bounded coverage/.history.json file by default. Set history_limit 0 to disable it.
• Existing configuration continues to work, but criterion-specific filters and threshold scopes now prefer coverage(:criterion) { ignore ... } and minimum ..., per: .... The legacy forms warn with their exact replacements, and deprecations :raise can enforce a completed migration.
• coverage.json advances additively to schema 1.3 for test-context, history, baseline-error, and production data. Previously published versioned schemas remain frozen for pinned consumers.

Enhancements

• The HTML report's source view renders the track_tests recording. A covered line no recorded test executed drains from green to a slate tint, with a "Covered outside tests" legend chip, so coverage produced only by load time, suite setup, or helpers stops passing for tested code at a glance. Every executed line carries a tests badge naming its count, and clicking it opens an inline panel listing the covering tests, the same ids in the same order simplecov tests file:line prints, each one selectable with a click for handing to a runner. Drained lines explain themselves in the same panel instead of listing nothing. The file header's Line coverage row splits its fraction by the same attribution ("Line coverage: 100.00% 21/30 relevant lines covered by tests, 9/30 relevant lines covered outside tests"), the legend's covered chip splits to match (green "Covered by tests" beside the slate "Covered outside tests"), keyboard access rides on real buttons with the report's focus ring, and the panel closes on Escape without closing the source dialog. The file list draws the same distinction: each line coverage bar splits its fill into the share recorded tests produced (in the usual band colour) and a slate share covered only outside them, in the file rows and the live-filtered totals row alike, and sorting by line coverage breaks ties on the by-tests share, so of two files at 100% the one whose coverage rests on its tests ranks above the one warmed by load time. All of it appears only when the report was generated with track_tests enabled, so other reports render exactly as before.

• simplecov patch reports coverage of just the lines a change touched, the question diff does not answer. Where diff compares two reports and asks whether the overall number moved — which a large or legacy project cannot shift in one pull request — patch reads git diff --unified=0 --merge-base <base>, intersects the added and modified line numbers with the current report, and prints line coverage — and, when the report measured branches or methods, branch and method coverage over the branches and methods those lines carry — for only that change, so a project sitting at 40% can still insist that everything it adds is tested. --minimum N exits non-zero below a floor (every measured criterion must clear it), composing with CI as a per-change gate alongside the existing thresholds; --base selects the ref to diff against (defaulting to the branch origin's HEAD points at, else main; in CI, the target branch or its merge-base); --find-renames follows a moved file instead of counting it as all-new; and --json emits the rows the other read-only commands do. Only files the report already carries are scored, and a line LinesClassifier deems never relevant stays out of the denominator the same way it stays out of a file's total, so a comment-only or whitespace change reads as nothing to cover rather than as a gap. A brand-new file that was never git added appears in no diff yet is still the change's work, so untracked files are scored too, every report-known line of them as new. The diff is anchored at the repository root rather than the working directory, so a run from a subdirectory reports the same change, and changed files resolve against the report by exact path, so a lookalike entry elsewhere in the report can never be scored in a changed file's place. A changed line beyond what the report knows for its file draws a staleness warning instead of silently scoring nothing, a git failure reports git's own words rather than a guess, and a path that matches more than one report entry names its candidates, in coverage and tests too, instead of a bare "no entry". Almost none of this is new machinery: the report already knows which lines are relevant and which were hit, leaving a hunk-header parser and path resolution against the report's root. Prior art is diff-cover, Codecov's patch status, and the undercover gem, which does this for Ruby but needs its own formatter and a git dependency to get there. See #1262.

• track_tests recording got a cost model and the levers to control it. Recording now settles at segment boundaries: consecutive tests share their boundary coverage snapshot (one snapshot closes one test's segment and opens the next, attributing any in-between code to the later test), which halves the per-test sampling cost outright, and the project-root check is memoized per file. On top of that, track_tests granularity: :file records one context per test file instead of per test, so the suite pays one snapshot per change of file in run order rather than one per test, and test selection needs no more than file identity anyway. On a real 1,756-test Minitest suite measuring line, branch, and method coverage, the two changes together cut tracking overhead from 52 seconds to 28 at the default granularity and to 13 at :file. The remaining floor is Ruby's own Coverage.peek_result copy, which scales with the criteria the run measures: a millisecond or two under line coverage alone, an order of magnitude more with branch and method tables, which the docs now spell out.

• simplecov tests answers which tests cover a file or line, from the terminal. Bare, it lists every test recorded under track_tests. With a path it narrows to the tests touching that file, and with path:line to one line. Text output is one test id per line and nothing else on stdout, sorted, so the list can feed a runner directly (simplecov tests lib/foo.rb:42 | xargs bundle exec rspec), with empty answers noted on stderr instead. --json emits a JSON array, and --input picks the report like the other read-only subcommands. It reads the contexts data in coverage.json, so it works on any report generated after track_tests was enabled, and explains what to enable when the recording is missing.

• simplecov tests --redundant lists the tests whose covered lines other tests also cover, the tests contributing no coverage of their own, computed from the same track_tests recording with no new measurement. The flag composes with the narrowing, so simplecov tests --redundant lib/foo.rb lists the redundant tests among those touching the file. The listed ids are candidates for review rather than a delete list: assertions and mutation-killing power are invisible to coverage, and two tests covering exactly the same lines subsume each other, so both are listed and deleting both would lose the lines. An empty answer over a real recording is good news and says so on stderr.

• simplecov affected selects the tests that touch changed code. It diffs the working tree against the merge base of a git ref (--base, defaulting to the branch origin's HEAD points at, else main) and HEAD, so uncommitted work counts as part of the change while commits that landed on the base after the branch point do not, includes untracked files, and prints the test files whose recorded tests touch the changed files, so the local inner loop can run simplecov affected --run bundle exec rspec instead of the whole suite. Everything after --run is the runner command, the selection is appended to it, and the exit status is the command's own. The set intersection is the easy half. The hard half is knowing when to distrust the map, because a test map is stale the moment something changes that no test mentions by name, so any changed file outside the tracked set fails open to the full suite, out loud: a changed Gemfile.lock, .simplecov, spec helper, runner configuration, or any file the report has no data for is named on stderr as the trigger, while stdout prints nothing, which a bare runner reads as run everything. Changed or brand-new test files always select themselves, recorded or not, a test file deleted by the change drops out of the answer, and a recorded test whose file no longer exists anywhere else reads as staleness rather than being silently skipped. --json emits the selection with its full_suite verdict and triggers for tooling, and --input picks the report like the other read-only subcommands. Like patch, the diff is anchored at the repository root, so a run from a subdirectory selects over the whole change, with --run starting the runner at that root, and changed files resolve against the report by exact path, so a lookalike entry elsewhere in the report can never stand in for a changed file the report does not carry. Built for the local inner loop first, because a wrong answer in CI is a green build on a broken change. See #1264. track_tests in a SimpleCov.start block samples coverage around every RSpec example and Minitest test, and stores the map in .resultset.json under a versioned contexts key beside the merged coverage, exposed as SimpleCov::Result#contexts with a covering(path, line) lookup. The data layer speaks of contexts rather than tests because the mechanism is general and matches the vocabulary a future Coverage library feature would use, while under track_tests every context is one test. Test ids are interned and each test's covered lines are packed into per-file bitmaps, which keeps the naive tests-times-lines storage in hand. Merges union the maps when every merged result recorded one and drop them out loud otherwise, across suites, concurrent runners, parallel workers, and simplecov collate alike, since a partial map would present one worker's tests as the whole run's. The Minitest wrapper installs through the minitest 5 plugin, and under minitest 6, whose autorun no longer discovers plugins, the moment Minitest::Test is defined. Other runners wrap their own units of work with SimpleCov.track_test. Tests running concurrently in threads inside one process cannot be told apart, because coverage counters are process-global, so such a process warns and stores no map rather than a misattributed one, while process-parallel workers each record their own. The serialized map carries a format version, so a future format reads as absent instead of being misread. The map also flows into coverage.json, the durable artifact downstream tools build on, as a document-level contexts array plus per-file hex bitmaps, under coverage.json schema 1.1 (schemas/coverage-v1.1.schema.json, with 1.0 staying frozen for pinned integrations, and the new keys optional so documents without recordings stay minimal). Opt-in because sampling around every test costs run time and the map costs space. Needs regular line coverage, so :oneshot_line is rejected at startup, because a line reports only its first hit ever and every later test's delta would miss it. See #1263.

• ActionView templates can be part of the report. cover_views in a SimpleCov.start block turns on eval coverage, which is what measures a template the suite renders, and compiles the templates it never renders so they appear at 0% rather than not at all. Rendering already produced usable data, because ActionView compiles each template with module_eval(source, identifier, offset) where the identifier is the template's own path and the offset cancels the def line its wrapper adds, so the generated code is attributed back to the .erb file at the template's own line numbers and nothing needs remapping. The gap was the other half: a template no test renders is never compiled, so Coverage never hears about it, and the views with no coverage were exactly the ones the report omitted. cover_views defaults to a Rails app's views, takes globs of its own for templates that live elsewhere, and honors skip like any other file in the report. The rails profile gains a matching Views group, which stays empty in a project that has not opted in. Needs CRuby 3.2 or later, which is what eval coverage needs. See #1265.

• The source view highlights each file by its own language rather than assuming Ruby. A .erb template used to be handed to the Ruby grammar, which declines to match markup and left the view almost entirely unhighlighted, so templates now go through an ERB grammar that marks up the tags and highlights what is between them as Ruby. It is a small grammar of SimpleCov's own rather than the one highlight.js ships, whose markup is delegated to a full XML grammar that carries a literal </script the report cannot inline (the whole report is one index.html with its JavaScript in a <script> element) and that would have cost around 5KB in every report written. The one shipped costs 627 bytes.

• The changelog is back at CHANGELOG.md in the project root, where the convention documented at keepachangelog.com puts it and where humans and tooling look for it. Moving it under docs/ was never what kept it out of the packaged gem: gem.files lists what ships, so the file stays unpackaged where it is. The gem's changelog_uri metadata follows it back, and the pre-0.18 entries stay at docs/Changelog.old.md. See #1272.

• cover_views reaches Haml and Slim, and its default glob is now app/views/**/*.{erb,haml,slim}. Nothing was needed to measure them beyond looking the handler up the way ActionView's own resolver does: both generate Ruby that keeps the template's line structure, so hits land on the lines their authors wrote. The same goes for any other language a project has registered a handler for, which needs only its extension named in a glob. An extension with no registered handler is now left out of the report instead of being compiled through ActionView's raw handler, which would have reported a project that has no Haml a file of static text for every .haml its default glob happened to match. The source view highlights Haml and Slim as themselves, the second through a small grammar of SimpleCov's own since highlight.js ships none.

• simplecov watch turns the report into something you look at while writing the test. It serves the report the way serve does, polls the tracked files for saves, re-runs the given command when something changes, and pushes a reload to the open tab over server-sent events the moment the report regenerates, with the result line naming the change and the coverage delta ("lib/result.rb changed, running 3 files... 100.00% (+0.40%)"), the number following the report's primary criterion. With a track_tests recording in the report a save re-runs only the tests touching the changed files, by the same selection walk simplecov affected uses and with the same fail-open rule, and without one every save runs the full command. The watched set is the report's own tracked files plus the recorded tests' files, polled by mtime rather than through a filesystem-event dependency, which also keeps report writes from triggering the next run. Child runs get a day-long merge window through the new SIMPLECOV_MERGE_TIMEOUT environment variable (honored by merge_timeout generally), so subset re-runs keep merging into a whole report across a long session. The report on disk stays byte-identical to a plain run's, with the reload listener added only on the way out of the server, and --open pops the report in the default browser on start. See #1269.

• simplecov show <path> prints annotated source in the terminal, the way go tool cover and llvm-cov show do: hit counts in the gutter, a caret marker naming each miss under its line, and branch and method misses annotated the same way when the report measured them. --uncovered-only collapses the answer to path:40,52-58,71, a form that greps, fits in a commit message, and hands a coding agent exactly the lines whose tests are missing, and --json emits the whole annotation as data (missed lines, per-line hits, marker labels) for editor integrations. With no path, --uncovered-only sweeps the whole project into one path:ranges line per file with misses, and a bare --json emits the same sweep as data. Colors follow the usual NO_COLOR, FORCE_COLOR, and --no-color rules. The source comes from the report itself when it embeds one, and otherwise from disk, accepted only while the file's line count still matches the report's, since annotating drifted source would put hit counts on the wrong lines. See #1270.

• simplecov status answers "is this report fresh?" from metadata the artifacts have carried all along: the report's age, the SimpleCov version and run that produced it, the recorded commit and how many commits HEAD has moved since, the measured totals, whether a track_tests map is present (and what to enable when it isn't), and the resultset's entries with their ages. --json emits the same facts as data. Every staleness question the change-aware commands raise now has a one-command answer.

• simplecov uncovered --missing appends the missed line ranges to each row (50.00% 5/10 lib/foo.rb missing 4-7,9), following the chosen criterion (zero-hit lines, or the lines missed branches and methods report on), and adds a missing array to each --json row, so the list says not just where to add tests but which lines they're for. --annotate github emits ::warning workflow commands instead of rows, one per contiguous missed range, so a plain GitHub Actions workflow gets inline diff annotations with no upload step and no code-scanning permissions.

• simplecov badge renders the report's percentage as a flat SVG badge in the shields.io style, to stdout or to a file with --output, so a README or CI artifact can carry the number straight from the local report with no badge service in the loop. The color follows the ladder badge services use for coverage (bright green at 90% and above, stepping down to red below 50%), --criterion picks the line, branch, or method percentage, and the label names the chosen criterion ("line coverage", "branch coverage", "method coverage") unless --label replaces it. The percent comes from the totals coverage.json already carries, so the badge always matches what the other read-only commands report.

• simplecov completions fish|bash|zsh prints a tab-completion script for the named shell, covering every subcommand with its description and each command's own options. The script is generated from the usage document itself rather than a hand-kept table, so a new command or option appears in completions the moment it is documented.

• The gem ships a man page, man/simplecov.1, covering every CLI command and option with the environment variables and files the commands honor. Like the shell completions, it is generated from the usage document (rake man regenerates it) so it cannot drift, and the suite fails when the committed copy is stale. RubyGems does not install man pages onto MANPATH, so read it with man $(gem contents simplecov | grep man/simplecov.1) or let a system package manager place it.

• Every CLI command answers --help / -h with its own slice of the usage text: the command's row, its options, and the shared options it accepts, instead of the full listing. It also replaces what optparse's built-in handler did before, which was to print a bare option summary under the host program's banner and exit the process from inside the parser.

• A checked-in per-file coverage baseline that only ratchets up, for legacy codebases where one minimum_coverage number does nothing and one minimum_coverage_by_file number lets the single worst file set the ceiling for the whole policy. simplecov ratchet writes .simplecov_baseline.yml from the current report, one floor per file per measured criterion, and the exit check fails any listed file that drops below its own floor. Rewriting only ever tightens: files that improved get their floors raised, files that regressed keep the floors they are now below (and are named in the summary), entries for deleted files are pruned, and new files never get an entry, so they answer to the real minimum_per_file standard (which files with an entry are exempt from, per criterion) rather than to a floor cut at whatever they launched with. The diff on the baseline file becomes the honest record of which direction the codebase moved, reviewable in the same PR as the change that moved it, the way .rubocop_todo.yml records offenses. The issue left open whether a floor should be a percent or a count of uncovered lines, since a percent moves when a file is edited without any coverage change at all. Each floor stores both: the percent is the policy, and the missed count is the dampener, so a violation requires a lower percent and more misses together, and an edit that only reshuffles covered lines fails nothing. A hand-written bare-percent entry (lib/foo.rb: 41.2) is accepted and decided by percent alone until the next ratchet records its missed count, while a malformed baseline fails loudly rather than silently un-enforcing every floor it carried. --init deliberately regenerates the file from scratch (new files added, floors reset), --dry-run prints without writing, --json emits the summary as data, and --baseline names the file, defaulting to the project's SimpleCov.baseline_file, which the command reads from .simplecov the way the read-only commands read coverage_dir. Baseline violations also land in coverage.json's errors section, under schema 1.2 (additive, with 1.1 staying frozen for pinned integrations). See #1268.

• maximum_missed and maximum_missed_per_file cap the number of misses instead of demanding a ratio, per criterion: uncovered lines, branch arms, or methods, counted in the criterion's own units. The suite-wide cap is a burn-down number, because "12 uncovered lines left" stays meaningful as the codebase grows and shrinks and is the sentence a team driving to 100% actually says, while the equivalent percentage moves with every edit. The per-file cap says what a per-file percent minimum cannot: a 2,000-line file at 99% hides 20 misses while a 10-line file at 80% fails over 2, so the cap holds every file to the same absolute budget. Both are verbs in the coverage block (coverage(:line) { maximum_missed 12; maximum_missed_per_file 5 }, with the same only: per-path overrides as minimum_per_file) and flat helpers (SimpleCov.maximum_missed line: 12, branch: 3), a fractional or negative cap is a configuration error rather than a silent truncation, and files with a baseline entry are exempt from the per-file cap per covered criterion, the same fall-through minimum_per_file honors. Violations land in coverage.json's errors section as maximum_missed and maximum_missed_per_file, part of schema 1.2. See #1268.

• formats :html, :json selects the bundled formatters by name, so the most-typed constants in every README snippet (SimpleCov::Formatter::HTMLFormatter and friends) are no longer required for the common combinations. :html, :json, :simple, and :baseline are the built-in names, formatter classes and ready-built instances mix freely beside them for third-party and option-carrying formatters, an unknown name raises naming the built-ins, and the bare call reads back the configured chain the way formatters does. The constant-spelled formatter / formatters forms are unchanged and equivalent.

• Entry filters are criterion-scoped coverage verbs now: coverage(:branch) { ignore :implicit_else, :eval_generated } and coverage :method, ignore: :eval_generated replace ignore_branches / ignore_methods, which had the criterion baked into their names the way the suffixed threshold verbs did. The flat setters are deprecated (warn-and-delegate, replacement named from their own arguments), with one behavior riding out the deprecation period: the coverage block enables the criterion it names, while the legacy setters record the filter without enabling.

• SimpleCov keeps a coverage history now, not just the last run. Every successful run appends an entry to coverage/.history.json: the percentages for every measured criterion, recorded for the suite, for every group, and for every file, plus a timestamp and the branch and commit when the project is a git checkout. The file is bounded (history_limit, 100 entries by default, 0 disables), written atomically with the corrupt-file tolerance .last_run.json has, and plain committable JSON so the trend can survive a clean CI checkout, while .last_run.json itself keeps working exactly as before. The history buys three things. simplecov history prints the trend in the terminal as Unicode sparklines, one per measured criterion, with the run rows beneath, and --file PATH follows one file's per-criterion trajectory the same way. drop_baseline :median / :branch let maximum_coverage_drop compare against the median of the recorded history, or against the newest recorded run on the current git branch, instead of against whatever ran most recently, so one run that dipped for an unrelated reason cannot quietly become the baseline the next run is judged against. And the history rides into coverage.json (and the HTML report's embedded data) as an optional top-level history array under schema 1.2, so other tools can draw the trend from the report artifacts. See #1267.

• Coverage can be measured in production to find dead code. require "simplecov/production" loads a standalone runtime (none of the reporting machinery, no formatters, no at-exit report) that is a no-op until SimpleCov::Production.start is called explicitly: it measures :oneshot_lines coverage, whose report-first-hit-only semantics are what make the overhead viable on live traffic, and a background thread drains the runtime's table every flush_interval into a pluggable sink instead of assuming one report per process at exit. Storage is the part a repository's coverage directory cannot be, so the sink is one store(coverage) method receiving root-relative paths mapped to line numbers: it must union-merge (each process holds only a slice), tolerate duplicates, and raise on failure, which makes the runtime keep the delta and retry, bounded by a configurable max_buffered_lines ceiling whose drops self-heal for still-running code because a drained line re-reports on its next execution. A locking single-file FileSink ships in the box; Redis or S3 implement the same method outside the gem. sample_rate duty-cycles measurement via Coverage.suspend/resume (rates below 1.0 need Ruby 3.2), a test suite's running Coverage always wins over start, forked workers re-start from the worker-boot hook and pick the inherited measurement back up, and configuration mistakes raise while environmental declines warn and no-op. Then simplecov dead-code --production PATH crosses the accumulated store with the test report, per line: run by both is normal, run in production but untested (--untested-in-production) is the highest-value place to add a test, tested but never run in production is possibly dead with only its own spec as a defender, and run by neither is dead. The default view prints the two deletion-candidate rows in the greppable path:ranges form, marks a file whose every relevant line skipped production as (entire file), names the window the data spans because the window is the evidence, and --json emits every category as data. Documented in docs/Production.md. See #1271.

• Production coverage reaches the reports. production_coverage "/path/to/production.json" names the store a SimpleCov::Production sink accumulated, and the bundled formatters cross it with the test coverage: the HTML report's file list gains a sortable "Last Run in Production" column (ascending floats the files production never touched, the deletion candidates, to the top), each source view marks the cross's two actionable cells (covered code production never ran gets a gray gutter stripe, missed code production did run gets a teal stripe and a "runs in production" badge), the file header summarizes the ran share with the last-run date, and the legend explains both exactly when the section is present. With simplecov serve that report is a browsable production-coverage web UI. coverage.json carries the same data as an optional production section (the window plus per-file lines and last_seen stamps) under schema 1.3, additive as usual, so downstream tools get the cross as data. Backing both, the bundled FileSink now stamps each file with the last drain that carried it (last_seen, optional on read so v1 stores and remote sinks that only fill the documented shape keep working, and honest recency because oneshot's clear-on-drain makes still-running code re-report every interval), and the runtime adds a fresh random share of flush_jitter (default a tenth of flush_interval) to every wait, so a fleet of workers booted together drifts apart instead of contending on the shared sink at the same instant forever. An unreadable store warns and the report generates without the section, because a missing night of production data should not fail the suite that measured the tests. simplecov dead-code reads the same stamps: rows gain a (last run 2026-08-03) annotation dating the store's last sighting of the file (on a dead or possibly dead row that means other lines of the file ran then, and no date means the window never saw the file at all), --json entries carry the full stamp as last_seen, and rows from a stamp-less store print bare, exactly as before. The setting is also the CLI's default: dead-code fills in --production from the production_coverage a project's .simplecov configures, the way ratchet reads baseline_file, so the configuration names the store once and everything that crosses reads it from there.

• deprecations :raise turns every deprecated API into a SimpleCov::ConfigurationError instead of a warning, so a project that has migrated can guard in CI against old spellings creeping back, and early adopters can hold themselves to the current surface as the configuration DSL evolves along its roadmap. The default stays deprecations :warn, the error names the replacement the way the warning does, and there is deliberately no silencing mode, because a deprecation you cannot see is a migration you never make.

• Threshold scope is now a uniform per: argument on the coverage block's verbs, instead of being baked into method names. minimum 80, per: :file sets the per-file default, minimum 100, per: "app/x.rb" (or a Regexp) overrides it for matching files, and minimum 95, per: group("Models") sets a group minimum, with maximum_missed taking the same targets for its per-file cap. One construct replaces three encodings (the bare verb, the _per_file / _per_group suffixes, and the only: keyword), so any future threshold verb gets every scope by composition rather than by minting new names. The suffixed forms (minimum_per_file, minimum_per_group, maximum_missed_per_file, and the flat SimpleCov.maximum_missed_per_file setter) are deprecated: they keep working and warn with the exact per: replacement built from their own arguments, and the older minimum_coverage_by_file / minimum_coverage_by_group deprecation messages now suggest the per: grammar directly instead of the intermediate spelling. A scope the enforcement cannot check yet is refused loudly rather than silently stored, which today means maximum_missed rejects per: group(...). The wider plan this is the first step of, covering the remaining matrix cells, the :eval pseudo-criterion, baseline unification, and the eventual single-surface 2.0 configuration, is written down in https://github.com/simplecov-ruby/simplecov/blob/HEAD/docs/Roadmap.md.

• SimpleCov::Formatter::BaselineFormatter auto-ratchets the per-file baseline at the end of every run, for teams that want floors to tighten continuously instead of by deliberate simplecov ratchet invocations. The semantics are exactly the CLI's (floors only tighten, regressed files keep the floors they are below and are named in the status line, deleted files are pruned, new files never get an entry), the file is rewritten only when a floor actually moved so an unchanged run leaves the working tree clean, and the exit checks still judge the run against the floors as they were when it started, which ratcheting cannot flip since it never loosens. See #1268.

• simplecov version (also --version and -v) prints the installed gem version, so a bug report can name the release it came from without a trip through gem list. It sits in the usage document like every other command, so the shell completions and the man page carry it too.

... (truncated)

Changelog

Sourced from simplecov's changelog.

1.2.0 (2026-09-04)

SimpleCov 1.2 adds change-focused coverage, per-test attribution, production coverage, and a substantially expanded CLI while keeping the existing configuration API working through deprecation aliases.

Highlights

• track_tests, simplecov tests, and simplecov affected connect covered lines to the tests that exercised them; the HTML report displays the same attribution and simplecov watch uses it for focused reruns.
• simplecov patch, per-file baselines, missed-count caps, and coverage history make coverage gates useful for both new changes and legacy codebases.
• SimpleCov::Production records low-overhead production line coverage, while simplecov dead-code and the bundled reports cross it with test coverage.
• ActionView templates can be measured with cover_views, including ERB, Haml, and Slim source highlighting.
• The CLI gains annotated source, report freshness, history, badges, shell completions, a man page, and richer machine-readable output.

Upgrade notes

• The minimum supported Ruby remains 3.2; JRuby 10 remains supported for line coverage.
• Successful runs now maintain the bounded coverage/.history.json file by default. Set history_limit 0 to disable it.
• Existing configuration continues to work, but criterion-specific filters and threshold scopes now prefer coverage(:criterion) { ignore ... } and minimum ..., per: .... The legacy forms warn with their exact replacements, and deprecations :raise can enforce a completed migration.
• coverage.json advances additively to schema 1.3 for test-context, history, baseline-error, and production data. Previously published versioned schemas remain frozen for pinned consumers.

Enhancements

• The HTML report's source view renders the track_tests recording. A covered line no recorded test executed drains from green to a slate tint, with a "Covered outside tests" legend chip, so coverage produced only by load time, suite setup, or helpers stops passing for tested code at a glance. Every executed line carries a tests badge naming its count, and clicking it opens an inline panel listing the covering tests, the same ids in the same order simplecov tests file:line prints, each one selectable with a click for handing to a runner. Drained lines explain themselves in the same panel instead of listing nothing. The file header's Line coverage row splits its fraction by the same attribution ("Line coverage: 100.00% 21/30 relevant lines covered by tests, 9/30 relevant lines covered outside tests"), the legend's covered chip splits to match (green "Covered by tests" beside the slate "Covered outside tests"), keyboard access rides on real buttons with the report's focus ring, and the panel closes on Escape without closing the source dialog. The file list draws the same distinction: each line coverage bar splits its fill into the share recorded tests produced (in the usual band colour) and a slate share covered only outside them, in the file rows and the live-filtered totals row alike, and sorting by line coverage breaks ties on the by-tests share, so of two files at 100% the one whose coverage rests on its tests ranks above the one warmed by load time. All of it appears only when the report was generated with track_tests enabled, so other reports render exactly as before.

• simplecov patch reports coverage of just the lines a change touched, the question diff does not answer. Where diff compares two reports and asks whether the overall number moved — which a large or legacy project cannot shift in one pull request — patch reads git diff --unified=0 --merge-base <base>, intersects the added and modified line numbers with the current report, and prints line coverage — and, when the report measured branches or methods, branch and method coverage over the branches and methods those lines carry — for only that change, so a project sitting at 40% can still insist that everything it adds is tested. --minimum N exits non-zero below a floor (every measured criterion must clear it), composing with CI as a per-change gate alongside the existing thresholds; --base selects the ref to diff against (defaulting to the branch origin's HEAD points at, else main; in CI, the target branch or its merge-base); --find-renames follows a moved file instead of counting it as all-new; and --json emits the rows the other read-only commands do. Only files the report already carries are scored, and a line LinesClassifier deems never relevant stays out of the denominator the same way it stays out of a file's total, so a comment-only or whitespace change reads as nothing to cover rather than as a gap. A brand-new file that was never git added appears in no diff yet is still the change's work, so untracked files are scored too, every report-known line of them as new. The diff is anchored at the repository root rather than the working directory, so a run from a subdirectory reports the same change, and changed files resolve against the report by exact path, so a lookalike entry elsewhere in the report can never be scored in a changed file's place. A changed line beyond what the report knows for its file draws a staleness warning instead of silently scoring nothing, a git failure reports git's own words rather than a guess, and a path that matches more than one report entry names its candidates, in coverage and tests too, instead of a bare "no entry". Almost none of this is new machinery: the report already knows which lines are relevant and which were hit, leaving a hunk-header parser and path resolution against the report's root. Prior art is diff-cover, Codecov's patch status, and the undercover gem, which does this for Ruby but needs its own formatter and a git dependency to get there. See #1262.

• track_tests recording got a cost model and the levers to control it. Recording now settles at segment boundaries: consecutive tests share their boundary coverage snapshot (one snapshot closes one test's segment and opens the next, attributing any in-between code to the later test), which halves the per-test sampling cost outright, and the project-root check is memoized per file. On top of that, track_tests granularity: :file records one context per test file instead of per test, so the suite pays one snapshot per change of file in run order rather than one per test, and test selection needs no more than file identity anyway. On a real 1,756-test Minitest suite measuring line, branch, and method coverage, the two changes together cut tracking overhead from 52 seconds to 28 at the default granularity and to 13 at :file. The remaining floor is Ruby's own Coverage.peek_result copy, which scales with the criteria the run measures: a millisecond or two under line coverage alone, an order of magnitude more with branch and method tables, which the docs now spell out.

• simplecov tests answers which tests cover a file or line, from the terminal. Bare, it lists every test recorded under track_tests. With a path it narrows to the tests touching that file, and with path:line to one line. Text output is one test id per line and nothing else on stdout, sorted, so the list can feed a runner directly (simplecov tests lib/foo.rb:42 | xargs bundle exec rspec), with empty answers noted on stderr instead. --json emits a JSON array, and --input picks the report like the other read-only subcommands. It reads the contexts data in coverage.json, so it works on any report generated after track_tests was enabled, and explains what to enable when the recording is missing.

• simplecov tests --redundant lists the tests whose covered lines other tests also cover, the tests contributing no coverage of their own, computed from the same track_tests recording with no new measurement. The flag composes with the narrowing, so simplecov tests --redundant lib/foo.rb lists the redundant tests among those touching the file. The listed ids are candidates for review rather than a delete list: assertions and mutation-killing power are invisible to coverage, and two tests covering exactly the same lines subsume each other, so both are listed and deleting both would lose the lines. An empty answer over a real recording is good news and says so on stderr.

• simplecov affected selects the tests that touch changed code. It diffs the working tree against the merge base of a git ref (--base, defaulting to the branch origin's HEAD points at, else main) and HEAD, so uncommitted work counts as part of the change while commits that landed on the base after the branch point do not, includes untracked files, and prints the test files whose recorded tests touch the changed files, so the local inner loop can run simplecov affected --run bundle exec rspec instead of the whole suite. Everything after --run is the runner command, the selection is appended to it, and the exit status is the command's own. The set intersection is the easy half. The hard half is knowing when to distrust the map, because a test map is stale the moment something changes that no test mentions by name, so any changed file outside the tracked set fails open to the full suite, out loud: a changed Gemfile.lock, .simplecov, spec helper, runner configuration, or any file the report has no data for is named on stderr as the trigger, while stdout prints nothing, which a bare runner reads as run everything. Changed or brand-new test files always select themselves, recorded or not, a test file deleted by the change drops out of the answer, and a recorded test whose file no longer exists anywhere else reads as staleness rather than being silently skipped. --json emits the selection with its full_suite verdict and triggers for tooling, and --input picks the report like the other read-only subcommands. Like patch, the diff is anchored at the repository root, so a run from a subdirectory selects over the whole change, with --run starting the runner at that root, and changed files resolve against the report by exact path, so a lookalike entry elsewhere in the report can never stand in for a changed file the report does not carry. Built for the local inner loop first, because a wrong answer in CI is a green build on a broken change. See #1264. track_tests in a SimpleCov.start block samples coverage around every RSpec example and Minitest test, and stores the map in .resultset.json under a versioned contexts key beside the merged coverage, exposed as SimpleCov::Result#contexts with a covering(path, line) lookup. The data layer speaks of contexts rather than tests because the mechanism is general and matches the vocabulary a future Coverage library feature would use, while under track_tests every context is one test. Test ids are interned and each test's covered lines are packed into per-file bitmaps, which keeps the naive tests-times-lines storage in hand. Merges union the maps when every merged result recorded one and drop them out loud otherwise, across suites, concurrent runners, parallel workers, and simplecov collate alike, since a partial map would present one worker's tests as the whole run's. The Minitest wrapper installs through the minitest 5 plugin, and under minitest 6, whose autorun no longer discovers plugins, the moment Minitest::Test is defined. Other runners wrap their own units of work with SimpleCov.track_test. Tests running concurrently in threads inside one process cannot be told apart, because coverage counters are process-global, so such a process warns and stores no map rather than a misattributed one, while process-parallel workers each record their own. The serialized map carries a format version, so a future format reads as absent instead of being misread. The map also flows into coverage.json, the durable artifact downstream tools build on, as a document-level contexts array plus per-file hex bitmaps, under coverage.json schema 1.1 (schemas/coverage-v1.1.schema.json, with 1.0 staying frozen for pinned integrations, and the new keys optional so documents without recordings stay minimal). Opt-in because sampling around every test costs run time and the map costs space. Needs regular line coverage, so :oneshot_line is rejected at startup, because a line reports only its first hit ever and every later test's delta would miss it. See #1263.

• ActionView templates can be part of the report. cover_views in a SimpleCov.start block turns on eval coverage, which is what measures a template the suite renders, and compiles the templates it never renders so they appear at 0% rather than not at all. Rendering already produced usable data, because ActionView compiles each template with module_eval(source, identifier, offset) where the identifier is the template's own path and the offset cancels the def line its wrapper adds, so the generated code is attributed back to the .erb file at the template's own line numbers and nothing needs remapping. The gap was the other half: a template no test renders is never compiled, so Coverage never hears about it, and the views with no coverage were exactly the ones the report omitted. cover_views defaults to a Rails app's views, takes globs of its own for templates that live elsewhere, and honors skip like any other file in the report. The rails profile gains a matching Views group, which stays empty in a project that has not opted in. Needs CRuby 3.2 or later, which is what eval coverage needs. See #1265.

• The source view highlights each file by its own language rather than assuming Ruby. A .erb template used to be handed to the Ruby grammar, which declines to match markup and left the view almost entirely unhighlighted, so templates now go through an ERB grammar that marks up the tags and highlights what is between them as Ruby. It is a small grammar of SimpleCov's own rather than the one highlight.js ships, whose markup is delegated to a full XML grammar that carries a literal </script the report cannot inline (the whole report is one index.html with its JavaScript in a <script> element) and that would have cost around 5KB in every report written. The one shipped costs 627 bytes.

• The changelog is back at CHANGELOG.md in the project root, where the convention documented at keepachangelog.com puts it and where humans and tooling look for it. Moving it under docs/ was never what kept it out of the packaged gem: gem.files lists what ships, so the file stays unpackaged where it is. The gem's changelog_uri metadata follows it back, and the pre-0.18 entries stay at docs/Changelog.old.md. See #1272.

• cover_views reaches Haml and Slim, and its default glob is now app/views/**/*.{erb,haml,slim}. Nothing was needed to measure them beyond looking the handler up the way ActionView's own resolver does: both generate Ruby that keeps the template's line structure, so hits land on the lines their authors wrote. The same goes for any other language a project has registered a handler for, which needs only its extension named in a glob. An extension with no registered handler is now left out of the report instead of being compiled through ActionView's raw handler, which would have reported a project that has no Haml a file of static text for every .haml its default glob happened to match. The source view highlights Haml and Slim as themselves, the second through a small grammar of SimpleCov's own since highlight.js ships none.

• simplecov watch turns the report into something you look at while writing the test. It serves the report the way serve does, polls the tracked files for saves, re-runs the given command when something changes, and pushes a reload to the open tab over server-sent events the moment the report regenerates, with the result line naming the change and the coverage delta ("lib/result.rb changed, running 3 files... 100.00% (+0.40%)"), the number following the report's primary criterion. With a track_tests recording in the report a save re-runs only the tests touching the changed files, by the same selection walk simplecov affected uses and with the same fail-open rule, and without one every save runs the full command. The watched set is the report's own tracked files plus the recorded tests' files, polled by mtime rather than through a filesystem-event dependency, which also keeps report writes from triggering the next run. Child runs get a day-long merge window through the new SIMPLECOV_MERGE_TIMEOUT environment variable (honored by merge_timeout generally), so subset re-runs keep merging into a whole report across a long session. The report on disk stays byte-identical to a plain run's, with the reload listener added only on the way out of the server, and --open pops the report in the default browser on start. See #1269.

• simplecov show <path> prints annotated source in the terminal, the way go tool cover and llvm-cov show do: hit counts in the gutter, a caret marker naming each miss under its line, and branch and method misses annotated the same way when the report measured them. --uncovered-only collapses the answer to path:40,52-58,71, a form that greps, fits in a commit message, and hands a coding agent exactly the lines whose tests are missing, and --json emits the whole annotation as data (missed lines, per-line hits, marker labels) for editor integrations. With no path, --uncovered-only sweeps the whole project into one path:ranges line per file with misses, and a bare --json emits the same sweep as data. Colors follow the usual NO_COLOR, FORCE_COLOR, and --no-color rules. The source comes from the report itself when it embeds one, and otherwise from disk, accepted only while the file's line count still matches the report's, since annotating drifted source would put hit counts on the wrong lines. See #1270.

• simplecov status answers "is this report fresh?" from metadata the artifacts have carried all along: the report's age, the SimpleCov version and run that produced it, the recorded commit and how many commits HEAD has moved since, the measured totals, whether a track_tests map is present (and what to enable when it isn't), and the resultset's entries with their ages. --json emits the same facts as data. Every staleness question the change-aware commands raise now has a one-command answer.

• simplecov uncovered --missing appends the missed line ranges to each row (50.00% 5/10 lib/foo.rb missing 4-7,9), following the chosen criterion (zero-hit lines, or the lines missed branches and methods report on), and adds a missing array to each --json row, so the list says not just where to add tests but which lines they're for. --annotate github emits ::warning workflow commands instead of rows, one per contiguous missed range, so a plain GitHub Actions workflow gets inline diff annotations with no upload step and no code-scanning permissions.

• simplecov badge renders the report's percentage as a flat SVG badge in the shields.io style, to stdout or to a file with --output, so a README or CI artifact can carry the number straight from the local report with no badge service in the loop. The color follows the ladder badge services use for coverage (bright green at 90% and above, stepping down to red below 50%), --criterion picks the line, branch, or method percentage, and the label names the chosen criterion ("line coverage", "branch coverage", "method coverage") unless --label replaces it. The percent comes from the totals coverage.json already carries, so the badge always matches what the other read-only commands report.

• simplecov completions fish|bash|zsh prints a tab-completion script for the named shell, covering every subcommand with its description and each command's own options. The script is generated from the usage document itself rather than a hand-kept table, so a new command or option appears in completions the moment it is documented.

• The gem ships a man page, man/simplecov.1, covering every CLI command and option with the environment variables and files the commands honor. Like the shell completions, it is generated from the usage document (rake man regenerates it) so it cannot drift, and the suite fails when the committed copy is stale. RubyGems does not install man pages onto MANPATH, so read it with man $(gem contents simplecov | grep man/simplecov.1) or let a system package manager place it.

• Every CLI command answers --help / -h with its own slice of the usage text: the command's row, its options, and the shared options it accepts, instead of the full listing. It also replaces what optparse's built-in handler did before, which was to print a bare option summary under the host program's banner and exit the process from inside the parser.

• A checked-in per-file coverage baseline that only ratchets up, for legacy codebases where one minimum_coverage number does nothing and one minimum_coverage_by_file number lets the single worst file set the ceiling for the whole policy. simplecov ratchet writes .simplecov_baseline.yml from the current report, one floor per file per measured criterion, and the exit check fails any listed file that drops below its own floor. Rewriting only ever tightens: files that improved get their floors raised, files that regressed keep the floors they are now below (and are named in the summary), entries for deleted files are pruned, and new files never get an entry, so they answer to the real minimum_per_file standard (which files with an entry are exempt from, per criterion) rather than to a floor cut at whatever they launched with. The diff on the baseline file becomes the honest record of which direction the codebase moved, reviewable in the same PR as the change that moved it, the way .rubocop_todo.yml records offenses. The issue left open whether a floor should be a percent or a count of uncovered lines, since a percent moves when a file is edited without any coverage change at all. Each floor stores both: the percent is the policy, and the missed count is the dampener, so a violation requires a lower percent and more misses together, and an edit that only reshuffles covered lines fails nothing. A hand-written bare-percent entry (lib/foo.rb: 41.2) is accepted and decided by percent alone until the next ratchet records its missed count, while a malformed baseline fails loudly rather than silently un-enforcing every floor it carried. --init deliberately regenerates the file from scratch (new files added, floors reset), --dry-run prints without writing, --json emits the summary as data, and --baseline names the file, defaulting to the project's SimpleCov.baseline_file, which the command reads from .simplecov the way the read-only commands read coverage_dir. Baseline violations also land in coverage.json's errors section, under schema 1.2 (additive, with 1.1 staying frozen for pinned integrations). See #1268.

• maximum_missed and maximum_missed_per_file cap the number of misses instead of demanding a ratio, per criterion: uncovered lines, branch arms, or methods, counted in the criterion's own units. The suite-wide cap is a burn-down number, becau...

  Description has been truncated

[suttondemlong]

@dependabot rebase

[suttondemlong]

@dependabot rebase