ReferenceBeginner3-5 min reference
Test Artifacts
When a CI test fails, the artifacts are the only way to debug it after the fact — the machine is gone. This sheet lists the artifacts worth producing, what each tells you, and sensible retention. It pairs with Flaky Test Debugging and HAR File Analysis (linked below).
The artifacts
| Artifact | Tells you | Produced by |
|---|---|---|
| JUnit/XML report | Pass/fail per test, trends | Most runners |
| Screenshot | UI state at failure | On-failure hook |
| Video | The run leading to failure | Cypress/Playwright |
| Trace | Step-by-step DOM/network/console timeline | Playwright trace |
| Console / browser log | JS errors, warnings | Runner |
| Server log | Backend errors with timestamps | App/CI |
| HAR | Full network capture | DevTools / proxy |
| Coverage report | What code the tests exercised | Coverage tool |
| HTML report | Human-readable summary | Allure / runner |
Retention guidance
| Artifact | Keep |
|---|---|
| Test reports (XML/HTML) | Long — trend analysis |
| Screenshots / video / trace | On failure; short TTL on pass (storage) |
| Logs | Days–weeks per policy |
| Coverage | Per build; trend the % |
Tips
- Capture screenshot + trace on failure — the trace usually solves it alone.
- Name artifacts with the test + timestamp + run id so they're findable.
- Don't archive everything on every green run — it balloons storage.
- Make artifacts downloadable from the CI run page, not buried on an agent.
Common mistakes
- No on-failure capture, so CI failures can't be reproduced.
- Publishing reports only on success.
- Keeping full video/trace for every passing run (cost).
- Artifacts with no run/test id — impossible to correlate.
// Related resources