Page 2 - PHPUnit

Testing an HTTP client without making real network calls requires realistic test doubles. The Guzzle MockHandler lets you precisely simulate success responses, error statuses, timeouts, and broken JSON payloads, covering every code path of a client with confidence.

Writing a separate test method for every input variation multiplies maintenance effort instead of test coverage. The PHPUnit data provider separates test logic from test data and turns ten near identical methods into one clearly readable test method with a dozen data sets.

willReturn() covers the vast majority of all mocking needs, return a fixed value, done. Sometimes that is not enough though: a mock needs to react differently depending on the argument it receives, or its behavior needs to change dynamically across several calls. That is exactly what willReturnMap and willReturnCallback are for. This article explains how both work and where the line sits, past which a mock already contains too much logic of its own.

A new attribute or a changed attribute set can silently break existing product data or frontend logic. Testing attribute setup scripts and the logic that depends on them catches such regressions before deployment instead of after.

PHPUnit finds runtime errors, but only if the corresponding tests exist. PHPStan and Psalm find type errors statically, before the code is ever executed. Only the combination of both approaches closes the gaps that each tool leaves open on its own. This article shows how to integrate PHPStan, Psalm and PHPUnit as a continuous quality chain in PHP projects.

Architecture rules that only exist in documents get broken. With PHPUnit, PHP-Arch and the Reflection API, layer boundaries, module dependencies and design rules can be formulated as executable tests, tests that fire immediately when a class calls into the wrong layer or a module introduces a forbidden dependency.

REST APIs and DTO mapping are two of the most common sources of bugs in PHP projects, and two of the hardest areas to test when the strategy is missing. Contract tests, schema validation and clean HTTP stubbing patterns make API tests reproducible, fast and meaningful.

A GraphQL mutation is more than a resolver with side effects. Anyone who doesn't model input types in the schema, writes business logic directly into the resolver, or fails to return errors as a structured response ends up with an API that is hard to test, document, and extend.

Some tests can only be written cleanly if PHPUnit runs them in a completely new PHP process: for example when legacy code defines constants that cannot be redefined, or when static state is so deeply entangled that a reset in tearDown is not enough. @runInSeparateProcess solves this reliably, but not for free: every isolated test starts its own PHP interpreter, which can noticeably drive up a suite's runtime if it is used too liberally.

Test-Driven Development is often either demonized or praised as a cure-all. The reality in PHP projects is more nuanced: TDD works brilliantly for certain classes of problems and creates unnecessary overhead for others. This article shows where the difference lies, with code, not theory.