WordPress Opens PHPUnit Test Cleanup for the 7.2 Release

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

After watching software projects age for three decades, one pattern is consistent: the test suite always tells you the honest story. Feature roadmaps lie. Screenshots lie. A test suite that quietly leaks state, asserts nothing, or phones home to the live internet — that tells you exactly how old the codebase feels on the inside.

WordPress is now old enough to have that problem sitting in plain sight, and mature enough to fix it in daylight. Lance Willett’s call this week for a PHPUnit test cleanup targeting the 7.2 release is not a headline feature. It is a piece of housekeeping that decides how fast every future release ships, and how much you can trust the green checkmark on a pull request.

In the Flash and Director years I sometimes still miss, there were no tests. You clicked through a project until you were tired, and if you were tired before it broke, the client caught it. Test suites are civilization. Civilizations need maintenance.

What is actually new

On September 8, Lance Willett published Join the PHPUnit Test Cleanup for 7.2 on Make/Core. The framing is blunt: WordPress runs around 31,000 PHPUnit tests on every commit, many of them leak state into other tests, some assert nothing, and several are coupled to live network calls. The Build/Test Tools component has adopted “reduce build time and load across wordpress-develop and related repos” as an explicit goal for the 7.2 cycle.

The post carves the work into eight tracks that contributors can pick up individually. Test isolation via random directory ordering is tracked in Trac #65893. Assertion audits — 101 @doesNotPerformAssertions annotations across 26 files, 98 of them concentrated in REST controller tests — sit in #40538. Replacing loose assertEquals() calls with strict assertSame() is #64895, with 501 candidates left across 124 files. Splitting oversized test classes into one class per unit is #65208. External HTTP calls are gated on PR #13407 and tracked in #63914. Trac #66074 targets the twenty-two test classes that account for half the suite’s total execution time. #65819 is the small-cleanups bucket. #65889 skips the PHPUnit matrix entirely on pull requests that only touch CSS or JavaScript.

The post also confirms a piece of infrastructure worth noting on its own: pushes to trunk now publish timing metrics to CodeVitals, which means a slow test is now visible as a data point, not a hunch. The Dev Chat agenda for September 9 puts the cleanup on the meeting itself, and the Core Build/Test Tools team meets every other Tuesday at 15:00 UTC in #core-build-test-tools, next on September 22.

Two adjacent signals are worth reading alongside this. The Performance Chat summary from the same day shows the query-cache work in PR #12220 and the script/style concatenation removal in PR #13084 are still the top-of-mind items for the performance team. And the WordPress PHPUnit handbook quietly documents that the test suite already supports random ordering, group filters, and Docker-based runs — the raw material is there, the discipline around it is what is being asked for.

Why it matters for WordPress and WooCommerce people

This is a story about the roof, not the wallpaper. Nobody markets a faster test suite on a release page. But every release you have ever installed, every plugin patch you have ever trusted, was gated by this suite. If half the wall-clock time is spent in twenty-two classes, then every merge-conflict rebase, every patch backport, every security release costs you disproportionate compute and disproportionate wait. If some tests assert nothing, then the green checkmark is a lie you have been paying for.

For agencies and plugin authors the practical read is more direct. WordPress core is publicly saying that state-leaky tests, unmocked HTTP calls, and loose equality assertions are technical debt. Your own plugin’s PHPUnit suite is almost certainly guilty of the same three sins. The 7.2 sprint gives you a moving target you can borrow from — the same Trac tickets, the same conventions, the same handbook references — instead of having to invent your own testing style guide.

The Store API and Cart/Checkout blocks in WooCommerce lean on WordPress’s REST controller test patterns; the assertion cleanup in the WordPress REST controller tests will show up in Woo’s own test hygiene sooner or later. The dual API work that shipped experimentally in 10.9 makes that inheritance more visible, not less.

There is also a governance point that WordPress people should not miss. A project that invites contributors to audit its own test hygiene in public — with tickets, numbers, and a metrics dashboard — is a project with room to grow. That is the maturity story I keep repeating to clients who ask why they should stay on WordPress instead of chasing the next hosted CMS. This is what it looks like.

What I would do (or not do) about it

If you contribute to core, or want to, this is one of the friendliest on-ramps in years. The tracks are small, the tickets are named, the review path is open. Pick one class from Trac #66074, profile it locally with the Docker workflow the PHPUnit handbook documents, and open a pull request that shaves a second off. That is a real contribution, and it is legible on a resume in a way that “helped triage” never quite is.

If you maintain a plugin, borrow the model. Grep your own suite for assertEquals and treat every hit as a candidate for assertSame. Grep for @doesNotPerformAssertions and audit each one — either add a real assertion or delete the test. Run your suite with a randomized test order and see what falls over; state leakage is embarrassingly common in plugin suites. And guard every external HTTP call with a mock, because a suite that hits the live internet is a suite that breaks on the day your CI runner cannot resolve DNS.

If you run a WordPress agency, budget a quarter for the equivalent audit on your own boilerplate. The internal starter kit you have been dragging from project to project probably carries the same three sins, and the fixed-price bug budget on your retainer clients is where those sins get paid for.

What I would not do is treat this as a symptom of the project being slow. It is the opposite. A team that can name its own slow classes, its own missing assertions, its own network coupling, and publish it on Make/Core with a metrics dashboard attached, is a team that has decided to be honest with itself. That is worth more than any release note.

The next Build/Test Tools meeting is September 22 in #core-build-test-tools. If you have ever wanted to work on the plumbing that keeps WordPress standing, that is the room.