Page 21 - Testing/E2E

Having a bats test suite for Bash scripts tells you nothing about which lines are actually executed. Code coverage with kcov closes that gap, shows line by line what tests really cover, and makes untested error paths visible long before they become a problem in production.

Without additional protective measures, GraphQL APIs are vulnerable to overloaded queries, introspection attacks, batching DoS, and data leaks through resolvers that are too permissive. This security review shows concrete attack scenarios and the matching countermeasures.

Postman, Insomnia, and curl become optional the moment PhpStorm has a full-featured HTTP client built in. GraphQL queries, REST endpoints, bearer-token authentication, and environment variables for different stages, all right inside the IDE, versioned in the repository, with no tool switching required.

List endpoints are the most complex parts of a REST API: they must support pagination, filtering and sorting consistently without bloating the API surface. The difference between a well designed and a poorly designed list endpoint comes down to three decisions: cursor or offset, which filter parameters are allowed, and how the meta object informs consumers.

In project discussions, E2E tests and penetration tests occasionally get treated as though a sufficiently comprehensive E2E test suite could eventually make a dedicated penetration test unnecessary, which rests on a basic misunderstanding of each test type's actual intent: an E2E test checks whether an application works as expected along known, previously defined user paths, while a penetration test deliberately tries to abuse the application through paths no development team considered while writing the test cases. This fundamentally different direction of thinking makes both test types valuable, complementary building blocks of a quality assurance strategy, but neither can structurally replace the other.

Running a Magento store into Black Friday without systematic load testing means relying on guesses instead of measurements. This article shows how load, stress, and spike tests differ, how to model realistic traffic patterns with k6, JMeter, and Locust, and which metrics beyond response time actually determine a store's true capacity.

Playwright records a complete trace of screenshots, DOM snapshots, network requests and console output for every failed test run. The Trace Viewer makes this recording searchable and shows exactly which click, which request, or which state caused a test to fail. That replaces hours of guesswork on flaky tests with targeted troubleshooting.

Running Jest without a clean TypeScript setup gives up the exact safety net you need most, right where errors are most expensive: in tests and mocks. This article shows how ts-jest and babel-jest differ, how to set up a type-safe jest.config.ts, and how to write mock functions, module mocks, and class mocks with real types instead of any.

Two teams that both need end-to-end tests for their Symfony application can arrive at completely different, equally correct answers when picking a tool. Panther writes browser tests as ordinary PHPUnit code with a real browser running behind it, which mainly benefits developers who already think in PHP. Behat describes the same scenarios in readable Gherkin syntax that a product owner without any programming background can understand, and even help write. This article compares both tools along the questions that actually decide things in practice: readability, developer speed, maintenance overhead, and whether you really only need one of the two.

Composables are the most important reuse mechanism in Vue 3, but how do you test reactive logic that registers lifecycle hooks, depends on timers, or makes fetch calls? Composable testing is not a special case of component testing, it is its own approach with its own tools and patterns.