We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A developer changed a utility function used by the billing module. The change was small, adjusting how decimal rounding worked. Manual testing of the developer's own feature passed. But nobody tested billing. Three months later, the finance team noticed that invoices were off by fractions of a cent. Multiplied across 200,000 transactions, the discrepancy totaled $47,000.
Automated tests would have caught this in seconds. A unit test for billing arithmetic would have run on every commit, flagged the rounding change immediately, and blocked the merge before the code ever reached production.
Test automation does not eliminate the need for human judgment in testing. It eliminates the need for humans to repeatedly verify things that machines verify faster, more consistently, and without forgetting edge cases.
| Layer | What It Tests | Speed | Tools |
|---|---|---|---|
| Unit tests | Individual functions/methods | Milliseconds | Jest, pytest, go test |
| Integration tests | Components working together | Seconds | Testcontainers, Supertest |
| E2E tests | Full user workflows | Minutes | Playwright, Cypress |
| Contract tests | API compatibility between services | Seconds | Pact |
| Performance tests | Response time, under load | Minutes to hours | k6, Artillery |
When to run which tests:
| Trigger | Tests to Run |
|---|---|
| Every commit | Unit tests, linting |
| Every PR | Unit + integration + contract |
| Pre-deploy | Unit + integration + E2E (critical paths) |
| Nightly | Full E2E suite + performance |
Key principle: tests must be fast. If the test suite takes 30 minutes, developers stop running it. Parallelize. Cache dependencies. Only run affected tests on PR (test impact analysis). The full suite runs in CI, not on every developer's laptop.
Shopify runs 300,000 tests. They use test impact analysis to identify which tests are affected by a change and only run those on PR. Full suite runs nightly. This keeps PR feedback under 5 minutes instead of 45.
When NOT to automate a test. When it changes frequently (UI layout tests that break on every design tweak). When the setup cost exceeds the value (complex E2E tests for a feature used by 3 people). When human judgment is needed (visual design review, UX flows).