Page 5 - PHPUnit

100% code coverage does not mean the tests actually check anything. Infection introduces automatic mutations into production code and measures whether PHPUnit tests detect these faults. The Mutation Score Index is the most honest quality metric you can apply to a test suite.

Anyone who writes assertEquals where assertSame is meant writes tests that pass even though the software is broken. Assertions are not boilerplate, they are the language in which a test describes what "correct" means. The right choice between equality, identity, type and structure decides whether a test is a safety net or delivers false confidence.

Testability is not created when the tests are written, but when the classes themselves are designed. Injecting dependencies, isolating side effects, and avoiding static calls builds code that can be tested without detours, no matter which test framework ends up being used. This article shows the design principles behind testable PHP code, beyond assertions and test runners.

In Magento 2 there are three fundamentally different test types with very different runtimes, maintenance costs, and areas of use. PHPUnit for unit and integration tests, MFTF for end-to-end browser tests, and REST API tests for the web service layer. The most common mistakes in Magento test strategies: too many MFTF tests, too few unit tests, and API tests that should really be logic tests.

Direct calls to new DateTime() or time() are the classic reason time-dependent logic is hard to test. A custom Clock abstraction fixes the problem at the root and lets you set fixed points in time inside PHPUnit tests.

PHPUnit does not just mark tests as passed or failed, it also marks some as risky. That is not a cosmetic detail, it is a signal about tests that are green but do not actually assert anything, or that misbehave in ways that matter: no assertion, unexpected output, or silent changes to global state. Teams that ignore these warnings end up with a test suite that looks trustworthy but is not.

Anyone who treats PHPUnit results as nothing more than terminal output is throwing away most of the value that automated tests provide. JUnit XML, HTML coverage, Teamcity output, and structured test duration reports make test results analyzable for CI systems, teams, and monitoring, well beyond a single build run.

Testing Doctrine repositories with pure mocks rarely exercises the actual query. An in-memory SQLite database runs DQL and query builder calls for real, without any database server, and makes repository tests run in milliseconds instead of seconds.

A PHPUnit suite that runs for twenty minutes gets ignored by the team. Tests stop being run locally, feedback loops get longer, and quality assurance ends up living exclusively in the CI pipeline, too late. This article shows where time in PHPUnit suites is actually lost and how to achieve measurable gains through bootstrap optimization, pcov, lean fixtures and test splitting.

A test suite with a few hundred tests runs completely in seconds, and nobody thinks about subsets. But once a project grows to several thousand tests, running the entire suite for every small change becomes impractical. PHPUnit's @group attributes and the command line's --filter parameter let you run exactly the tests relevant to the current change, for example only fast unit tests or only a specific module, provided the team agrees on a consistent taxonomy.