Learn Cypress - Real-world Use Cases & Patterns

#Introduction

All the techniques you have learned are now put to the test on real cases. Episode 20 covers patterns from the three most common types of applications: ecommerce, SaaS onboarding, and dashboard flows, plus test design best practices, balancing the testing layers, and end-to-end reliability patterns.

This is the application episode: no new syntax, but how to structure a suite that makes sense for a real product.

#Use Cases: Ecommerce, SaaS Onboarding, and Dashboard Flows

#Ecommerce: The Shopping Flow

Ecommerce has core flows that must be tested: catalog, cart, and checkout. Prioritize the flows that generate revenue:

Core ecommerce flow

it("menyelesaikan pembelian produk", () => {
  cy.intercept("GET", "/api/produk*").as("katalog");
 
  cy.visit("/katalog");
  cy.wait("@katalog");
  cy.get("[data-cy=produk]").first().click();
  cy.get("[data-cy=tambah-keranjang]").click();
  cy.get("[data-cy=keranjang]").should("contain.text", "1");
 
  cy.get("[data-cy=checkout]").click();
  cy.contains("Terima kasih").should("be.visible");
});

cy.intercept("GET", "/api/produk*").as("katalog") waits for the catalog data to finish loading before interacting. The ecommerce flow is focused on the main purchase path users use most often.

#SaaS Onboarding

Onboarding determines retention. Test the flow from signup to account activation:

SaaS onboarding flow

it("pengguna baru menyelesaikan onboarding", () => {
  cy.visit("/daftar");
  cy.get("[data-cy=email]").type("user@example.com");
  cy.get("[data-cy=password]").type("rahasia123");
  cy.get("[data-cy=daftar]").click();
 
  cy.get("[data-cy=langkah-1]").should("be.visible");
  cy.get("[data-cy=pilih-peran]").select("engineering");
  cy.get("[data-cy=lanjut]").click();
 
  cy.contains("Workspace siap").should("be.visible");
});

cy.get("[data-cy=pilih-peran]").select("engineering") fills in an onboarding step. Each step is verified before moving on, so the failure location is easy to trace if onboarding changes.

#Dashboard Flows

Dashboards are rich in data and filters. Focus tests on the correctness of filters and the displayed data:

Dashboard filter flow

it("memfilter laporan berdasarkan rentang tanggal", () => {
  cy.intercept("GET", "/api/laporan*").as("laporan");
 
  cy.visit("/dashboard");
  cy.get("[data-cy=rentang]").select("30h");
  cy.wait("@laporan");
 
  cy.get("[data-cy=total]").should("not.be.empty");
});

cy.get("[data-cy=rentang]").select("30h") changes the range filter. cy.wait("@laporan") makes sure new data has loaded before checking the results — avoiding assertions against stale data.

#Best Practices for Test Design and Prioritization

#Start with High-Risk Flows

Prioritize tests by risk and frequency: flows used by millions of users, flows involving money, and flows that break often. Use a simple matrix:

• High frequency + high risk: must have E2E.
• High frequency + low risk: integration tests are enough.
• High risk + low frequency: E2E with medium priority.

Every test you write should answer the question: what important flow does it protect, and what happens if this test fails?

#Design That Reads Like a Scenario

The best tests read like a description of a flow, not an implementation. When the test name and steps tell a clear story, maintenance becomes easier and debugging faster.

#Balancing Unit, Integration, and E2E Tests

#A Balanced Pyramid

Back to episode 0: unit tests are the most numerous and fastest, integration tests are in the middle, and E2E tests are the fewest and most expensive:

Unit: 70% - cepat, terisolasi, tanpa browser.
Integration: 20% - kerja sama modul, sebagian memakai browser.
E2E: 10% - alur pengguna penuh, paling mahal.

The Unit: 70% proportion is a guideline, not a law. E2E should answer questions no other layer can — complete user flows — and not duplicate assertions that belong in unit tests.

#Avoiding E2E Duplication

Do not test in E2E what unit tests already guarantee. E2E only needs to verify that correct units integrate correctly. This keeps the suite lean and fast.

#End-to-End Reliability Patterns

#Patterns That Make E2E Reliable

A few patterns that raise reliability:

• Stub the network with cy.intercept() for stable data.
• Wait for end conditions, not durations.
• Use data-cy for all selectors.
• Set up data in the task API, not through the UI.
• Run tests in parallel with balanced load.

#Keeping Flows Independent

Every E2E test should be able to run on its own and as part of the suite. Independence means no hidden ordering between tests — the key to a suite that can be parallelized and split without fear.

#Closing

Episode 20 connected technique with real practice: ecommerce flows, SaaS onboarding, and dashboard filters, risk-based test prioritization, a balanced unit-integration-E2E pyramid, and reliability patterns that keep flows dependable and independent.

Key takeaways:

• Prioritize E2E for high-risk, high-frequency flows.
• Stub dynamic data so flows are deterministic.
• Do not duplicate unit assertions in E2E.
• Maintain pyramid proportions: many unit tests, few E2E tests.
• Every test should be independent and able to run on its own.

In the next episode, episode 21, we will cover ecosystem and tools — Cypress plugins, dashboard, and community resources, supporting tools like Testing Library, Storybook, and Percy, cross-browser support, and learning resources and documentation.