Every change to the modernised PADI platform passes through a layered set of automated checks before it can reach your users. Each layer answers a different question — does the code still behave correctly, do the real user journeys still work end to end, and is the experience still fast and accessible. Together they give us a dependable safety net: regressions are caught early, close to the change that caused them, and quality is measured rather than assumed.
Our unit testing is delivered through PHPUnit — the framework Drupal itself is built and tested with — at two complementary levels:
Unit
Pure logic, in isolation
Exercises a single class or method on its own, with dependencies mocked. Runs in milliseconds — ideal for business rules and edge cases.
Kernel
Real Drupal, minimal footprint
Boots a minimal Drupal kernel — real container, database, and entity/config/plugin APIs — to confirm our code integrates correctly with Drupal, without full-site overhead.
Together, they help us
Lock in correct behaviour. Business logic and Drupal integrations become executable specifications — documented, and continuously verified.
Catch regressions at the source. When a change breaks existing behaviour, the failing test points straight at the affected logic, long before it reaches an environment or a reviewer.
Refactor with confidence. The team can restructure and improve the code knowing the suite will flag any behaviour that shifts unintentionally.
Keep feedback fast. Because they avoid a full-site bootstrap, hundreds of tests run in seconds, keeping the development loop tight.
Runs in CI on every pull request. Before any change is accepted, the suite re-runs and flags anything the change has broken — a failure blocks the merge, keeping broken code off the main branch.
Where PHPUnit verifies the parts, Playwright verifies the whole. It drives a real browser through complete user journeys — loading, clicking, typing, navigating — across the full stack: the front end, the Drupal back end, and the integrations behind them.
This is our end-to-end regression layer: it confirms the journeys your users depend on still work after changes, exactly as a person would experience them.
What it helps us achieve
Protects critical journeys. Key flows — navigation, search, forms and other core interactions — are validated as complete paths, not just isolated components.
Tests the way users experience the site. Running a genuine browser against a live environment exercises the front end and back end together, surfacing issues that only appear once everything is wired up.
Gives fast, repeatable confidence. A journey that would take a person several minutes to click through is replayed consistently, without human error, every time it runs.
Reduces manual effort. Repetitive verification is automated, freeing the QA team to focus on exploratory, higher-judgement testing.
Lives in the same CI pipeline, but is not triggered on a push or pull request. Instead QA triggers it manually, on demand, to smoke test an environment — for example after a deployment to staging — while still using CI’s consistent, managed infrastructure.
Lighthouse guards what users feel but code alone can’t guarantee: speed and accessibility. It measures Google’s Core Web Vitals and runs automated accessibility checks against our pages.
LCP
Largest Contentful Paint
How quickly the main content becomes visible — perceived load speed.
INP
Interaction to Next Paint
How responsively the page reacts to taps and clicks.
CLS
Cumulative Layout Shift
How visually stable the page stays as it loads.
Alongside performance, the accessibility audit checks pages against established best practices. Together, these checks help us:
Hold a performance budget. Core Web Vitals are measured on every run, so speed is treated as a requirement rather than an afterthought.
Keep the experience accessible. Automated checks flag common issues — missing labels, insufficient colour contrast, structural problems — that affect users relying on assistive technology.
Prevent silent drift. Because it runs continuously, a change that quietly degrades performance or accessibility is caught immediately, not months later.
Support SEO and reach. Strong Core Web Vitals contribute to search visibility, protecting a channel that matters to PADI’s audience.
Integrated as a CI quality gate. We set thresholds for Core Web Vitals and accessibility; if a change pushes scores below them, the check fails and blocks the change — the same as a failing test.
04
In SummaryQuality, checked continuously and confirmed deliberately
Across these three layers, each dimension of quality has a dedicated owner. PHPUnit proves the code is correct and Lighthouse keeps it fast and accessible — both running automatically on every pull request and blocking anything that regresses — while Playwright lets QA confirm the real user journeys end to end, on demand, against any live environment.
The outcome for PADI is a dependable safety net: problems are caught early, close to the change that caused them, and quality is measured rather than assumed.
Step 1
Pull request raised
A developer proposes a change for review.
→
Step 2 · CI gates
PHPUnit + Lighthouse
Run automatically on the PR. A failure blocks the merge.
→
Step 3 · QA on demand
Playwright smoke test
Triggered manually in CI to verify a deployed environment.