Page 3 - 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.

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.

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.

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.

Magento integration tests built on XML fixtures are fragile, hard to maintain and barely readable. PHP based fixtures, the DataBuilder pattern and consistent use of the ObjectManager produce test data that is readable, reliable and easy to adjust, without fixture files that break after every schema update.

Anyone who blindly treats every collaborator as a Mock loses the semantic expressiveness of their tests. Stub, Fake, Spy, Mock and Dummy have clearly defined roles, and whoever confuses these roles ends up writing tests that hide bugs instead of surfacing them.

Legacy code is code without tests, and it cannot be changed safely without tests. The way out of this dilemma begins with characterization tests: tests that document the actual behavior, not the desired one. Introduce seams, break static dependencies and extract classes step by step, without changing a single line of production logic before the first test is green.

Anyone who only runs PHPUnit from the command line is giving up most of PhpStorm's productivity. Run Configurations, coverage reports right in the editor, test filters down to a single method, and the Docker remote interpreter turn PhpStorm into a complete testing environment, without ever leaving the terminal behind for good reason.

The most common experience in PHP projects: tests are hard to write because the production code makes them hard. Dependencies instantiated directly, global state, too many responsibilities crammed into one class. Testability is not a random byproduct, it is the result of concrete design decisions made in the production code.