Page 17 - Testing/E2E

CLI commands are often the least tested part of a PHP application. Yet these are exactly the commands that drive cron jobs, migrations, deployments and critical batch operations. The exit code is the only communication channel between a process and the calling system, and it has to be correct so CI pipelines and orchestrators can react to failures.

Visual regression tests promise to reliably catch any unintended visual change to a page by automatically comparing a current screenshot against a stored reference image. In practice, though, it quickly becomes clear that the underlying diffing algorithm decides whether this approach actually succeeds: an overly simple, strict pixel-by-pixel comparison flags dozens of meaningless deviations from anti-aliasing and sub-pixel rendering on every single run, while an overly lenient comparison silently waves through real, relevant regressions.

Introducing visual regression testing means making a fundamental choice: a managed service like Percy, Chromatic, or Applitools with a ready-made review UI and usage-based billing, or Playwright's free toHaveScreenshot comparison with self-managed baseline images. This article compares cost, complexity, and pull request workflows across all four approaches and shows which solution fits which team size.

Exploratory testing thrives on spontaneously discovering unexpected behavior, not on rigid scripts. Claude does not replace that creative process, but supports it as a co-pilot: sharpening the test charter, applying heuristics, and structurally capturing observations during the session.

Anyone who implements an API before the design is settled blocks frontend teams and forces QA engineers into manual follow-up. API-first reverses the order: the OpenAPI specification comes first, enabling mocking for the frontend and contract tests for QA, so all teams can develop in parallel without waiting on each other.

Using PHPUnit in PhpStorm is trivial when PHP is installed locally. With Docker interpreters, Magento-specific bootstrap files and integration tests that require a running database, the configuration becomes more complex. This guide shows how to solve each of these cases cleanly.

A failed end-to-end test typically returns only an error message and a stack trace at the test framework level, revealing nothing about what actually happened in the backend during that particular test run. Test observability closes exactly this gap by correlating distributed tracing, structured logs, and metrics with the given test run, so a single glance at a red test immediately reveals whether the cause lies in the frontend, in a specific backend request, or in a third-party integration, instead of having to painstakingly reconstruct manually which service was involved at which point in time.

AI-generated tests deliver a working test suite in seconds, but without human review it stays unclear whether they actually verify the intended behavior or merely lock in the current, possibly buggy code state. This article shows how Magento developers can use Claude Code productively for test generation, tell genuine edge cases apart from mere line coverage, and systematically review test quality.

Testing Pinia stores in isolation takes more than instantiating a store and calling an action. Between createPinia and createTestingPinia, real versus mocked actions, and cross-store dependencies lie decisions that determine the meaningfulness and maintainability of an entire test suite.

Repository tests with mocks check the wrong layer. A mock repository cannot detect a SQL syntax problem, an index problem, or an N+1 bug. Real database access in tests is expensive, but irreplaceable at the right spots. The art lies in knowing exactly where those spots are and how to implement database isolation reliably.