PHP Testing

Coding standards are the PSR family — PSR-1 and PSR-12 — checked with tools like PHP_CodeSniffer. The main test runners are PHPUnit and Pest. To isolate code from external dependencies you mock them: PHPUnit's createMock(), the Mockery library, or test doubles injected through a constructor (DI) seam. You assert against the double instead of hitting a real network or database.

A unit test exercises one class in isolation, with its collaborators replaced by doubles, and by default does not boot the framework. A feature test boots the application, so it can hit a route with $this->get('/orders'), touch the database and assert on the HTTP response. Feature tests prove the wiring; unit tests pinpoint the fault.

Arrange builds the object under test and its inputs. Act invokes exactly one behaviour on it, usually a single method call. Assert compares the observed outcome with the expectation. Keeping the phases separate and acting once leaves the test a single reason to fail, so a red test tells you precisely which call broke.

Pest is a DSL layered on PHPUnit, not a separate engine: you write it('...', fn() => ...) closures instead of methods on a TestCase, and PHPUnit still executes them. Its assertions, mocks and configuration keep working, and classic TestCase classes sit in the same suite. The authoring style changes, not the runner.

It parses the source and reasons about types and reachability without executing anything: calls to undefined methods, wrong argument and return types, conditions that can never be true, unreachable code, missing null checks. It also reads docblock generics the engine ignores. Its strictness is a level you raise gradually on legacy code.

A data provider is a method returning an iterable of argument sets. PHPUnit runs the test once per set, passing each one as the test method's parameters, and reports every set as a separate test with its own name — so a failure names the exact input. A foreach inside a single test would stop at the first bad case and hide all the rest.

A stub returns canned data and verifies nothing — it only lets the code under test run. A mock sets call expectations up front, such as expects($this->once()), and fails when they are not met. A spy records calls so you assert on them after the act. Interaction checks couple the test to how the code calls its collaborators.

SQLite is a different engine, not a fast MySQL: different dialect, looser typing, different constraint and date behaviour. Green on SQLite proves nothing about the queries production will run — that is the failure you hit. Test against the same engine as production, and keep it fast with transaction rollback in CI.

PHPUnit builds a fresh test-class instance for every test method, runs setUp() before it and tearDown() after. The constructor runs outside that lifecycle: it has a fixed signature you may not break, it has no paired teardown, and a failure in it is not reported as an ordinary test failure. setUp() is the supported seam.

Inject a clock instead of calling the global. Declare a Clock interface with now(): int, take it in the constructor and call $this->clock->now(). Production wires a SystemClock that returns time(); the test passes a frozen clock with a fixed timestamp. No global is touched, so the tests stay isolated and can still run in parallel.

It wraps each test in a database transaction and rolls it back at the end, so the schema is migrated once and every test starts from the same state without truncating tables. That is why it is fast. It breaks when the code under test commits, or when a second connection — a queue worker, a browser — cannot see the uncommitted rows.

They cover different windows. A runtime type declaration only fires on a line a request actually reaches; a test only proves the paths it exercises. A static analyser checks every path in the source before anything runs, and understands docblock generics the engine cannot express. CI runs all three.

Line coverage only records which lines executed. Infection mutates the source — flips a > into >=, negates a condition, drops a return — reruns the suite and asks whether any test now fails. A surviving mutant is a defect your tests would not have caught. A suite with no assertions still reports full coverage.

A mock encodes your assumption about the provider, and nothing checks that the assumption still holds. Add consumer-driven contract testing: your suite records the requests it makes and the responses it expects as a pact, and the provider replays that pact against its real implementation in its own pipeline. Your suite stays fast; their build goes red when they break you.

It renders the view, compares the output with a committed snapshot file and fails on any difference. That is cheap to write and catches unintended markup changes across a large view layer. The cost is that it asserts on everything: a legitimate whitespace or class-name edit fails too, and the reflex is to regenerate the snapshot — quietly approving a regression.

Split it in two. At the dispatch site, fake the queue and assert the job was pushed with the right payload — the controller's contract ends there. Then test the job's handle() as a unit, with the gateway and the mailer injected as doubles, so no real charge or email fires. Cover retries and the failure hook by making a double throw.