PlaywrightPHP

Capture

Capture browser evidence with the right artifact: screenshots for state, traces for diagnosis, video for motion, files for outputs.

Artifacts are the evidence you keep after a browser run. A passing test usually needs none. A failing test needs enough context to answer three questions:

  • what did the user see?
  • what did the browser do?
  • where is the evidence stored?

The safe default is: capture nothing on success, capture a screenshot and trace on failure, and upload the artifact directory from CI.

Choose evidence by question

Question Start with Continue with
What was visible at failure time? screenshot trace if the cause is unclear
Which action or request caused the failure? trace filtered console or network logs
Did motion, scrolling, or focus behave incorrectly? video trace for the action sequence
Did the product render the right printable document? PDF stable text or business-data checks
Did the product create the expected file? download artifact application-side file validation

Do not enable every artifact everywhere. Heavy artifacts slow CI and make failures harder to scan.

Start with the cheapest evidence that can answer the question. Add another artifact only when the first one leaves a specific uncertainty.

Separate failures from product output

A screenshot or trace explains a failed run. A PDF, CSV, or downloaded report may be the product output under test. They need different policies.

Failure evidence should usually be short-lived and uploaded only after a failure. Product output may need to survive successful runs for review or further validation. Do not delete or retain both categories with one broad rule.

Set one storage policy

Use one ignored directory for a run:

text
var/playwright-artifacts/

Rules:

  • keep it out of public/;
  • add it to .gitignore;
  • include the test or scenario in file names;
  • upload it from CI only on failure unless the artifact is the product output;
  • redact logs before writing them;
  • keep retention short unless a product or compliance rule requires more.

CI upload strategy

Upload artifacts only when they are needed:

yaml
- name: Upload browser artifacts
  if: failure()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-artifacts
    path: var/playwright-artifacts/**
    retention-days: 7

For product files, such as a generated CSV or PDF that the test intentionally produces, upload on success when the artifact is part of the review process. For debugging evidence, upload on failure.

Verify the policy before trusting it

Make one test fail intentionally. Confirm the expected artifact exists, download it from CI, and open it. A green upload step does not prove the file contains the failing action or visible state.

Check four failure modes:

  • a fixed filename was overwritten by a parallel test;
  • the context closed after the upload step, so the video was incomplete;
  • the artifact path was outside the directory CI collects;
  • the screenshot, trace, or logs exposed credentials or personal data.

Choose the next investigation