Page 4 - Testing/E2E

A custom hook too often gets tested only indirectly through the component that uses it. That hides bugs in the hook logic and makes tests unnecessarily complex. renderHook from React Testing Library lets you check a hook's state, side effects and async updates directly, with no artificial host component at all.

Growing end-to-end test suites slow down every CI pipeline once tests run sequentially. This article shows how to distribute test suites across multiple CI workers, optimize load balancing based on real runtimes instead of raw file count, avoid resource conflicts on shared databases and sandbox accounts, and achieve noticeably faster test runs with Cypress Cloud, Playwright sharding, and GitLab CI matrix jobs.

Test code often gets a free pass on type discipline because deadlines are tight, a mock gets copy-pasted, or it is supposedly just a test. Yet tests are exactly where type regressions in the code under test need to be caught reliably. This article covers practical typed mocking patterns using vi.mocked, satisfies, and mock factories, plus unknown and zod as replacements for any in loosely shaped test data.

Anyone who checks every field of an API response individually with expect often misses silent breaking changes such as new required fields, changed types or removed enum values. Schema validation against JSON Schema or OpenAPI catches exactly these cases automatically, cuts test code significantly, and integrates smoothly into Cypress, Playwright and the CI pipeline, so frontend and backend reliably honor the same contract.

Letting tests rerun until they pass quietly pushes real bugs and race conditions out of sight and slowly erodes trust in the test suite itself. This article shows how to configure Cypress and Playwright retries correctly and how teams can turn repeated test runs into an early warning system instead of a convenient free pass.

Teams that only cover a GraphQL API with end-to-end tests end up with a slow, brittle test suite. Teams that only write unit tests miss errors in schema composition. A well-designed GraphQL testing pyramid deliberately spreads test effort across the resolver level, the schema level, and real user flows, with clear criteria for which layer catches which class of error.

Most PHP projects either have too many unit tests for code that depends on database state, or too few tests at the right level. The test pyramid is not an academic concept, it is a practical tool for deciding which test type solves which problem most efficiently.

A pull request with a new feature and its accompanying tests often gets read in code review such that the actual production logic is scrutinized carefully, while the accompanying test code only gets a brief glance, as long as the tests are formally green and look plausible at a glance. This unequal distribution of attention is risky, because a test that checks nothing meaningful but still stays green conveys a deceptive sense of safety that only reveals itself as empty once an actual bug surfaces in production later.

Manually generating client SDKs from an OpenAPI spec is error-prone and blocks releases. Running openapi-generator inside a CI/CD pipeline generates, validates and publishes SDKs automatically on every spec change, with Spectral linting, breaking change detection and contract tests acting as gates.

Shift-left testing means catching issues during design and while writing code, instead of leaving them to a dedicated QA phase at the end. Developers who write and own their own end to end tests, use static analysis consistently, and no longer throw code over the wall to QA, shorten feedback cycles noticeably and significantly reduce the cost of every bug found.