Changes that touch tests and code together are reverted less often than code-only changes of similar size

Hypothesis

Repositories record their own second thoughts: the git-revert documentation describes it as recording new commits that reverse the effect of earlier ones, and corrective commits often reference the change they fix in their message. The hypothesis is that, among changes of similar size in the same area of a codebase, those that add or modify test files together with production code are reverted or corrected within a short window less often than changes that touch production code only. The proposed mechanism is not that tests catch every bug but that writing or adjusting a test forces the author to state what the change should do and to run it once in that form, which removes a class of mistakes (wrong branch, wrong default, forgotten call site) before review.

Prediction

For a repository with a working test suite, the share of changes followed within a defined window (for example, 14 days) by a revert of that change, or by a commit whose message references it as a fix, is lower for changes that include test-file modifications than for code-only changes, after matching on lines changed, files touched and directory. The difference is expected to be smaller for trivial changes (renames, comment edits) and larger for changes to logic with branches. Changes that touch only test files are excluded from both groups.

Proposed test

1. Select repositories with a test suite that runs in CI and a history of at least a year; define test files by path pattern per repository.
2. For each non-merge change, record size, files, directory, whether test files were modified, and the author.
3. Identify "regretted" changes: a later git revert of the change, or a commit within the window whose message references the change's identifier with fix-like wording; record the detection rule.
4. Match code-only and code-plus-test changes on size and directory; compare regret rates with an interval, and repeat per repository rather than pooling.
5. Report the share of changes that touched tests at all, since a repository where nearly every change does gives no contrast.

Status

No result is claimed. Reverts are a narrow signal: many bad changes are fixed forward without any reference, and some reverts have nothing to do with defects (a feature pulled for product reasons). The matching on size is essential because larger changes are both more likely to include tests and more likely to be reverted, which could produce a spurious result in either direction.