You write tests on your laptop. But they do their real job on a build server. A machine that runs your whole suite automatically every time someone changes the code. In most teams this is called CI.
Four things are different there, and they surprise almost everyone.
The machine is slower, and there is no screen.
Build servers are usually smaller than your laptop, and they run the browser without showing it. Any test that quietly depended on your fast machine will start failing. That is not bad luck. The server is finding timing assumptions you did not know you had made.
Tests run at the same time.
To save time, most teams split the suite across several machines. Two files can run at the same second, against the same environment. This is why every rule about independent tests and unique data matters. A suite that only works in one fixed order breaks the day someone turns on parallel runs.
Nobody is watching.
When a test fails on your machine, you see it happen. On the server, all you get is what the run saved. So keep videos and screenshots turned on, and make sure your team knows where to find them.
A slow suite gets ignored.
This one is about people, not code. If the suite takes forty minutes, developers stop waiting for it. They merge their change and check later. Then they stop checking. Now you have a suite that costs money and catches nothing.
Keep it fast:
- Save the login with
cy.session. - Create test data with API requests, not by clicking forms.
- Stub the slow or hard states.
- Keep browser tests for the flows that truly need a browser.
And the worst problem of all: a flaky test. A test that fails at random teaches your team a terrible habit. They see red, they re-run it, it goes green. After a month, they re-run every red build without looking. Then one day a real bug fails the build, someone re-runs it, and the bug ships.
I have seen this exact story finish badly. A payment bug reached production on a Friday afternoon. The build had caught it. Three people had re-run that build without opening the report, because everyone had learned that red usually meant nothing.
So treat a flaky test as a bug. Fix it, or delete it. A test nobody believes is worse than no test at all.
Remember this: your suite is useful only when the team trusts it and waits for it. Speed and stability are not extras. They are the job.
Reference: Continuous Integration.