Page 12 - Testing/E2E

Anyone who runs PHP inside a Docker container also wants PhpStorm to work with that same PHP version, for autocompletion, navigation, tests and debugging. The Docker interpreter in PhpStorm connects the IDE and the container without requiring PHP to be installed locally. This article shows how to configure it correctly.

Classic unit tests check individual, hand-picked examples. Property-based testing flips that around: instead of writing examples, you define properties that must hold for every valid input, then let fast-check generate thousands of random cases to uncover exactly the edge cases a human writing tests by hand tends to overlook.

Anyone who treats PHPUnit results as nothing more than terminal output is throwing away most of the value that automated tests provide. JUnit XML, HTML coverage, Teamcity output, and structured test duration reports make test results analyzable for CI systems, teams, and monitoring, well beyond a single build run.

A Docker Compose project with a PHP container, MySQL, Redis, and Nginx is up and running quickly, but fully integrating PHPStorm so that the interpreter, debugger, database data source, and Composer all work from within the IDE requires targeted configuration in several places.

Anyone who writes Bash scripts as a monolithic block can hardly test them in any meaningful way. Only splitting the script into pure, isolated functions makes unit tests for Bash possible in the first place, and with bats-core you can check return values, stdout and error paths just as structured as in any other programming language.

Teams that build Magento applications without systematic security testing rely on luck instead of tools that reliably surface vulnerabilities. Static analysis with PHPStan and Psalm catches dangerous data flows directly in the source code, while dynamic scanners like OWASP ZAP run real attacks against a running staging environment. This article shows how both approaches work together, where their limits lie, and when each investment pays off.

shUnit2 brings the classic xUnit style with assertEquals and setUp/tearDown into the Bash world, bats-core instead describes tests as readable @test blocks in a BDD style. Both frameworks solve the same underlying problem, but with different syntax, different CI integration, and different strengths depending on project size.

Anyone who resolves GraphQL filters in Magento naively through raw SQL or direct model queries builds up technical debt. The correct path runs through the SearchCriteriaBuilder, with type-safe arguments in the schema, clean delegation in the resolver and testable filter logic in the service contract.

Teams that test Alpine.js components in Hyva themes only through full end to end runs wait minutes for feedback on every small change and build tests that depend on network, database and session state. Cypress Component Testing mounts individual components in isolation inside a real browser, without a Magento backend and without a full page build, delivering results in seconds instead of minutes.

From the schema definition through the ResolverInterface to DI configuration, error handling and integration tests: the complete path to a production-ready Magento GraphQL resolver, no shortcuts.