A failure on your machine is easy. You watch it happen, you open the runner, you scrub back through the command log.
A failure on the build server is a line of text in a log nobody read, at three in the morning, on a machine that no longer exists. What you collect automatically is all you will ever have.
Cypress collects three kinds of evidence, and two of them are on by default.
Screenshots on failure. When a test fails during cypress run, Cypress saves a screenshot of the moment it failed, into cypress/screenshots. This single image answers most questions: was the page blank, was there an error banner, was a dialog covering the button.
Video of the run. Cypress can record the whole spec as video, saved to cypress/videos. Turn it on in config:
module.exports = defineConfig({
video: true,
e2e: { baseUrl: 'http://localhost:3000' },
});
Video is heavier and slower, so many teams record only failures, or turn it off for fast feedback runs and on for nightly ones.
A machine-readable report. The terminal output is fine for a person and useless for a dashboard. A reporter writes results in a format other tools can read:
npm install --save-dev mocha-junit-reporter
npx cypress run --reporter mocha-junit-reporter
JUnit XML is the common format. Nearly every CI system reads it and will show you a test list with pass and fail counts, trends over time, and which test started failing on which commit.
Now the part people skip, and it is the reason this lecture is not just a list of settings.
A report is only useful if the test names are useful. A JUnit file full of entries called "works correctly" tells you nothing. This is where the naming rule from earlier pays off: name the test after the behaviour, and the report becomes a readable list of what your app does.
Keep the artifacts. Screenshots and videos are written on the build machine, which is usually destroyed after the run. Every CI system has a way to upload them as build artifacts, and if you skip that step you have collected evidence and then thrown it away. I have watched a team spend a day reproducing a failure whose screenshot had existed and been deleted.
Read the failure count, not the colour. A build that fails with one test red is a bug. A build that fails with forty red is usually the environment: the app did not start, a migration did not run, the login user was deleted. Those need different responses, and the number tells you which you have before you open anything.
Remember this: collect the screenshot, upload the artifacts, and name tests so the report reads like a list of behaviours.
Reference: Screenshots and videos.