Page 9 - Testing/E2E

Most testing approaches verify that a system works correctly under expected, clean conditions, while chaos engineering takes the opposite path and deliberately, in a controlled way, introduces faults into a running system, say a service outage, elevated network latency, or a lost database connection, to observe how resilient the overall system actually is to that disruption. This discipline assumes complex, distributed systems will fail sooner or later regardless, and turns that into the deliberate choice to experience that failure in a controlled way, at a time of your own choosing, rather than uncontrolled in the middle of the night because of a real incident.

A GraphQL schema without a review process evolves in an uncontrolled way: breaking changes, inconsistent naming conventions, and missing documentation creep in. This article shows which points should be checked before every merge, manually and automatically with tooling.

This article explains what the Magento Functional Testing Framework actually does, how its declarative XML structure fundamentally differs from imperative Cypress or Playwright code, and in which project phases MFTF still remains the right choice. Developers get a clear breakdown of when backend tests with MFTF make more sense than modern JavaScript E2E tests for the storefront.

A REST API without a test strategy is a promise without a guarantee. Symfony offers a complete ecosystem for every test layer with HttpClient, Panther and PHPUnit, from fast unit tests for validation logic to contract tests that make sure API consumers and API providers speak the same interface specification.

A test suite that grows organically alongside production code over years almost inevitably accumulates the same kinds of decay as the production code itself: copied test cases that differ in only a single value, outdated helper functions nobody dares to delete anymore, and setup blocks that look nearly identical from one test case to the next but are never quite the same. Unlike production code refactoring, though, test code refactoring lacks a crucial safety net: there is no second test suite checking whether the first one still works correctly, which is why refactoring tests themselves needs particular care.

AI-assisted code review reliably catches mechanical problems like style violations, obvious bugs, and missing error handling before human review time gets spent. This article shows what tools like Claude Code are genuinely good at in review, where they fail at business logic and architectural understanding, and how both layers can be combined without replacing human accountability.

@testing-library/user-event simulates complete interaction sequences like a real browser, while fireEvent dispatches a single DOM event synchronously. The difference seems small but often determines whether a test catches real bugs or blindly passes right over them.

Playwright fixtures replace fragile beforeEach blocks and shared global test state with clearly defined, reusable building blocks for setup and teardown. Once you understand built in fixtures like page, context and browser and start writing your own with test.extend, you get tests that run in parallel, never interfere with each other, and avoid duplicated setup code across files.

Mocking composables is more complicated in Vue tests than it first appears, because composables often combine global state, network access, and reactive side effects. With vi.mock, targeted dependency injection, and provide/inject as a testing seam, components can still be tested reliably in isolation, without dragging along real composable implementations.

Anyone maintaining three separate compose files for dev, test and CI ends up writing configuration three times and regularly forgets to sync changes across them. Docker Compose Profiles solve this problem at the root: services are only started when the matching profile is active, one file for every environment.