CI/CD · Ship safely, repeatedly
What tests should run in CI?
Short answer
Run fast deterministic unit and integration tests on every change, plus security and dependency checks. Put slower end-to-end tests for critical paths in the pipeline, but do not make every commit wait for the entire suite.
The merge-blocking suite should answer whether the change is safe to integrate. That means tests that are fast, reliable and relevant to the changed code, with broader suites running in parallel or at a later gate.
- Linting and type checks catch cheap errors before tests run
- Unit tests cover logic and edge cases with minimal setup
- Integration tests verify contracts with databases, queues and services
- End-to-end tests cover a small number of critical user journeys
- Dependency, secret and container scans run on every build or on a schedule
npm ci
npm run lint
npm run typecheck
npm test -- --runInBand
npm run test:integrationFollow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you handle flaky tests?
- 2Should end-to-end tests block every merge?
- 3How do you choose what to test at which level?
- 4What do you do when the test suite takes too long?
Say it in the interview
I keep the merge-blocking suite fast and deterministic: lint, type checks, unit tests and focused integration tests. Security scans also run early. End-to-end tests cover only the critical journeys and can run in parallel or as a later gate. If a test is flaky I quarantine it with an owner instead of normalizing retries, because trust in the suite is the whole point.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.