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
Unit tests verified cart arithmetic. Integration tests verified the cart API. Manual QA tested the checkout flow on Chrome. Everything worked. But in production, users reported that items disappeared from their cart when they switched between mobile and desktop browsers. The cart was stored in localStorage on one device and server-side on another. No test had covered the cross-device synchronization path because no test exercised the full flow from the user's perspective.
The gap: unit and integration tests verify that individual components and their connections work. E2E tests verify that complete user journeys work. A user does not call your API directly. They click a button, which fires a JavaScript event, which calls your API, which writes to the database, which triggers a update, which re-renders the page. Each layer adds a chance for something to break.
E2E tests simulate exactly that. They open a real browser, click real buttons, fill real forms, navigate real pages, and verify real outcomes. They catch the bugs that only appear when the entire stack is assembled.
Tool comparison:
| Tool | Browser Support | Speed | Debugging | Best For |
|---|---|---|---|---|
| Playwright | Chrome, Firefox, Safari, mobile | Fast (parallel by default) | Trace viewer, video | Multi-browser, modern teams |
| Cypress | Chrome, Firefox, Edge (no Safari) | Medium | Time travel debugger | Developer-friendly, SPA-focused |
| Selenium | All browsers | Slow | Limited | Legacy, broad browser support |
Playwright won the E2E market in 2023-2024. Microsoft open-sourced it in 2020, and it has since surpassed Cypress in npm downloads. The key advantages: native multi-browser support (including Safari), auto-waiting that eliminates most flakiness, and a trace viewer that records every network request, DOM snapshot, and console log for failed tests.
What to E2E test (and what NOT to):
| User Journey | Worth E2E Testing? | Why |
|---|---|---|
| Registration and login | Yes | Revenue-critical, touches auth + email + DB |
| Checkout and payment | Yes | Money path, must never break |
| Search and browse | Maybe | High-traffic but less complex |
| Every form validation rule | No | Unit test these, E2E is too slow |
| Every CSS layout variation | No | Use visual regression (Chromatic, Percy) |
| Admin CRUD operations | No | Low traffic, integration tests suffice |
The rule of thumb: 5-15 E2E tests for critical user journeys. Not 500. E2E tests are slow (seconds to minutes each), brittle (UI changes break them), and expensive to maintain. Use them only for the flows where failure means lost revenue or lost users.
It is easy and good
“It is really nice and good Please join the course”