<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh" -->

---
title: Untouched tests are half the proof | daily.dev
description: Sebastian Bergmann argues that the ideal bug fix only adds a new regression test without modifying any existing tests — the new test proves the bug is fixed,...
canonical: https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Untouched tests are half the proof | daily.dev
og:description: Sebastian Bergmann argues that the ideal bug fix only adds a new regression test without modifying any existing tests — the new test proves the bug is fixed,...
og:url: https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh
og:image: https://api.daily.dev/og/posts/OpfJFjNMh.png
og:image:alt: Untouched tests are half the proof
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Untouched tests are half the proof

**[PHPUnit Expert](https://daily.dev/sources/phpunit-expert)** · 10 min read · 1 upvotes · 0 comments

## Summary

Sebastian Bergmann argues that the ideal bug fix only adds a new regression test without modifying any existing tests — the new test proves the bug is fixed, while untouched tests prove nothing else broke. He validates this thesis against PHPUnit's own commit history, finding three patterns when existing tests do change: tests coupled to implementation details (structural tests that break on internal refactors), behavioural changes mislabelled as bug fixes (where the old behaviour was actually documented), and 'neutralised tests' — correct tests silenced under merge pressure with XFAIL markers rather than properly investigated. The analysis of 191 candidate commits shows that genuine rewrites of existing expectations are rare, and each case calls for a specific response: decouple structural tests, communicate behavioural changes properly, or stop silencing failures you don't have time to understand.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://phpunit.expert/articles/untouched-tests-are-half-the-proof.html>

## Questions this post answers

### Why would a bug fix in PHPUnit break every test method in an unrelated unit test file?

A unit test that constructs an internal value object directly, such as HookedProperty, can break across every method when the fix threads a new constructor parameter through that object. In one PHPUnit fix, adding a fifth parameter to HookedProperty's constructor broke every test in PropertyTest even though none of the actual behaviour being asserted had changed, revealing that the tests were coupled to an implementation detail rather than to observable behaviour.

_Developers untangling brittle test coupling from real regressions can find PHPUnit-specific writeups like this through daily.dev._

### What are the different reasons an existing test might need to change when fixing a bug?

There are three distinct reasons: the test was coupled to an implementation detail rather than observable behaviour and breaks on unrelated refactors; the fix is actually a deliberate change to documented behaviour mislabeled as a bug fix; or the test was previously neutralised, for example silenced with an XFAIL marker under merge pressure, and the real fix simply uncovers and repairs that earlier damage.

_Teams deciding how to respond when a fix touches existing tests can track this kind of practical testing discipline on daily.dev._

## Similar posts on daily.dev

- [Unit tests mark territory more than squash bugs](https://daily.dev/posts/unit-tests-mark-territory-more-than-squash-bugs-tjmwlmfzx) · Lobsters · 0 upvotes · 1 comments
- [Test-Driven Security](https://daily.dev/posts/test-driven-security-rqc3xemtd) · PHPUnit Expert · 2 upvotes · 0 comments
- [A Better Alternative to Reducing CI Regression Test Suite Sizes](https://daily.dev/posts/a-better-alternative-to-reducing-ci-regression-test-suite-sizes-ulzdrg7zc) · InfoQ · 0 upvotes · 0 comments

---

Tags: [#testing](https://daily.dev/tags/testing), [#php](https://daily.dev/tags/php), [#phpunit](https://daily.dev/tags/phpunit)

[View this post on daily.dev](https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Untouched tests are half the proof","url":"https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh"},"datePublished":"2026-07-22T03:51:13.037Z","dateModified":"2026-09-13T20:54:44.414Z","description":"Sebastian Bergmann argues that the ideal bug fix only adds a new regression test without modifying any existing tests — the new test proves the bug is fixed,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/901a68f7560d8bd2fe413224a8c2b97c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/901a68f7560d8bd2fe413224a8c2b97c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"PHPUnit Expert","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"PHPUnit Expert","logo":"https://media.daily.dev/image/upload/s--FMZoysoG--/f_auto,q_auto/v1774964057/logos/phpunit-expert?_a=BAMAMiWQ0","url":"https://daily.dev/sources/phpunit-expert"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"testing,php,phpunit","timeRequired":"PT10M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"PHPUnit Expert","item":"https://daily.dev/sources/phpunit-expert"},{"@type":"ListItem","position":3,"name":"Untouched tests are half the proof"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/untouched-tests-are-half-the-proof-opfjfjnmh#faq","mainEntity":[{"@type":"Question","name":"Why would a bug fix in PHPUnit break every test method in an unrelated unit test file?","acceptedAnswer":{"@type":"Answer","text":"A unit test that constructs an internal value object directly, such as HookedProperty, can break across every method when the fix threads a new constructor parameter through that object. In one PHPUnit fix, adding a fifth parameter to HookedProperty's constructor broke every test in PropertyTest even though none of the actual behaviour being asserted had changed, revealing that the tests were coupled to an implementation detail rather than to observable behaviour. Developers untangling brittle test coupling from real regressions can find PHPUnit-specific writeups like this through daily.dev."}},{"@type":"Question","name":"What are the different reasons an existing test might need to change when fixing a bug?","acceptedAnswer":{"@type":"Answer","text":"There are three distinct reasons: the test was coupled to an implementation detail rather than observable behaviour and breaks on unrelated refactors; the fix is actually a deliberate change to documented behaviour mislabeled as a bug fix; or the test was previously neutralised, for example silenced with an XFAIL marker under merge pressure, and the real fix simply uncovers and repairs that earlier damage. Teams deciding how to respond when a fix touches existing tests can track this kind of practical testing discipline on daily.dev."}}]}
```

