CI/CD & DevOps65 min total · 17 parts
CI/CD Pipelines Explained: From Push to Production
Part 9 of 17 · ~1 min
Testing in CI: What Runs, and When
Once the nightly schedule trigger exists, the team has to actually decide what runs where, and the honest answer is that a check earns a different spot in the pipeline depending on how fast it is and how much it can be wrong about:
| Layer | Checks | Roughly how fast | When it runs |
|---|---|---|---|
| Unit | The receipt-total math, currency rounding, one function at a time, nothing real behind it | A few seconds, the whole suite | Every push, every PR |
| Integration | worker actually talking to a real Redis and a real Postgres, wired the way Compose wires them locally | Fifteen to thirty seconds | Every push to main, alongside the build |
| End-to-end | A real browser uploading a real receipt image and watching a row appear in the UI | Three to five minutes, and it flakes occasionally on a slow screenshot comparison | Nightly only, via the schedule trigger |
The blind spot this table is honest about showing up almost immediately: two weeks in, someone renames a CSS class on the upload button as part of an unrelated cleanup. Unit tests don't touch the DOM at all, so they're green. Integration tests hit worker directly over its API and never open a browser, so they're green too. The only thing that would have caught it is the one check running once a night — and it does, the next morning, which is a full workday later than a push-triggered check would have been. That's the actual trade being made by keeping E2E off every push: real coverage, on a real delay, in exchange for not making every commit wait three to five minutes for a browser to screenshot a button.