PlaywrightPHP

Audits

Turn accessibility, performance, console, and product checks into readable reports.

An audit is a targeted check that produces a result humans can act on.

Use audits for accessibility, performance, console errors, security headers, product readiness, or release evidence. Keep them scoped and explain what a failure means.

Mental model

An audit should have:

  • a clear target;
  • a stable environment;
  • an actionable threshold;
  • readable output;
  • a retention rule for reports.

If a failure does not tell someone what to fix, the audit is not ready to gate CI.

What belongs in an audit

  • accessibility violations for key pages;
  • performance budgets for known flows;
  • console errors owned by the application;
  • required headers or metadata;
  • release checklist evidence.

Start as reporting. Promote to a hard failure after the signal is stable.

Minimal CI pattern

Keep the audit small enough that a failure points to one owner:

php
$reportDir = __DIR__.'/../var/playwright-artifacts/audits';
is_dir($reportDir) || mkdir($reportDir, 0777, true);

$consoleErrors = [];
$page->events()->onConsole(static function ($message) use (&$consoleErrors): void {
    if ('error' === $message->type()) {
        $consoleErrors[] = $message->text();
    }
});

$page->goto('https://app.example.test/dashboard');
expect($page->getByRole('heading', ['name' => 'Dashboard']))->toBeVisible();

file_put_contents(
    $reportDir.'/dashboard-console.json',
    json_encode(['errors' => $consoleErrors], JSON_PRETTY_PRINT)
);

self::assertCount(0, $consoleErrors, 'Dashboard should not emit console errors.');

That pattern has three parts:

  1. collect one signal;
  2. write a report to a deterministic artifact path;
  3. enforce a threshold that the team can defend.

When not to gate CI

Do not fail builds on a new audit until the output is stable and owned. Start by uploading the report, review the noise for a few runs, then promote the threshold to a failure.

Do not combine accessibility, performance, console, and security checks into one assertion. Separate reports make failures easier to route.

Common pitfalls

  • Combining unrelated checks into one noisy report.
  • Setting thresholds nobody can defend.
  • Auditing third-party content without ownership.
  • Keeping reports outside CI artifacts.
  • Calling an audit complete when it only proves one browser or one viewport.

Go next