E2E Testing with Cypress for Your Website

E2E Testing with Cypress for Your Website

A failure in a critical user scenario means lost conversions and damaged reputation. Manual regression tests consume hours before each release, and catching bugs after deployment is costly. Our solution: implement end-to-end tests with Cypress that verify every user path from click to backend. Automating regression slashes manual testing costs and speeds up releases.

Unlike Selenium or Puppeteer, Cypress runs in the same event loop as the application. As Cypress documentation states: 'Cypress runs in the same event loop as your application'. This gives a built-in time-travel debugger, automatic element waiting without sleep(), and full control over network requests via cy.intercept(). We use it on React, Vue, Angular, and even plain JavaScript.

What Problems Does E2E Testing with Cypress Solve?

• Flaky tests – the main pain of E2E. Cypress automatically waits for elements and eliminates sleep(), removing instability.
• Long regression runs – with parallel execution on CI, time drops from hours to minutes, a 90% reduction.
• Debugging complexity – time-travel allows stepping through each action to trace failures.

Case Study: E-Commerce Order Flow

For one client, we covered a checkout flow integrating Stripe. We wrote 15 tests checking successful payment, card decline, timeout, and cart return. Using cy.intercept() to mock Stripe responses made tests fully deterministic. Result: regression time dropped from 4 hours to 15 minutes (a 94% reduction), and production bug frequency fell by 30%. Typical clients save $5,000–$10,000 annually in testing costs.

Why Cypress Is the Top Choice for E2E Testing?

Cypress enables writing tests 2–3 times faster than Selenium, thanks to automatic waiting and no WebDriver requirement. It integrates directly with frameworks, intercepts all network requests, and provides time travel – seeing each test step in the UI. This reduces debugging time for flaky tests by 40%.

What We Cover with Tests?

• Authentication: login, registration, password recovery – using API mocks for environment independence.
• Core flows: checkout, add-to-cart, entity creation – full chain from UI to database.
• Navigation and routing: redirects, breadcrumbs, 404 pages.
• Error handling: service unavailability, invalid data, network timeouts – so users never see a blank screen.

We test not only the happy path but also edge cases: empty carts, invalid coupons, session expiration. This ensures a resilient user experience.

Implementation of E2E Tests with Cypress

Installation and Configuration

npm install -D cypress
npx cypress open  # first run – creates directory structure

cypress/
├── e2e/          # test specifications
├── fixtures/     # static test data
├── support/
│   ├── commands.ts   # custom commands
│   └── e2e.ts        # global configuration
└── cypress.config.ts

// cypress/e2e/auth/login.cy.ts
describe('Login', () => {
    beforeEach(() => {
        cy.visit('/login');
    });

    it('successfully logs in with valid credentials', () => {
        cy.get('[data-cy="email-input"]').type('[email protected]');
        cy.get('[data-cy="password-input"]').type('password123');
        cy.get('[data-cy="login-btn"]').click();

        cy.url().should('include', '/dashboard');
        cy.get('[data-cy="user-name"]').should('contain', 'John');
    });

    it('shows error on invalid credentials', () => {
        cy.get('[data-cy="email-input"]').type('[email protected]');
        cy.get('[data-cy="password-input"]').type('wrongpass');
        cy.get('[data-cy="login-btn"]').click();

        cy.get('[data-cy="error-message"]')
            .should('be.visible')
            .and('contain', 'Invalid email or password');
    });
});

// Mock API – test does not depend on backend
it('displays products from API', () => {
    cy.intercept('GET', '/api/products*', {
        fixture: 'products.json',
        statusCode: 200,
    }).as('getProducts');

    cy.visit('/products');
    cy.wait('@getProducts');

    cy.get('[data-cy="product-card"]').should('have.length', 10);
});

// Verify request payload
it('sends correct payload on form submit', () => {
    cy.intercept('POST', '/api/orders', (req) => {
        expect(req.body).to.deep.include({ productId: 1, quantity: 2 });
        req.reply({ statusCode: 201, body: { orderId: 100 } });
    }).as('createOrder');

    // ... actions
    cy.wait('@createOrder');
    cy.get('[data-cy="success-message"]').should('be.visible');
});

CI/CD Integration

We configure test runs in GitHub Actions, GitLab CI, or Jenkins. For parallel execution, we use Cypress Dashboard or GitHub Actions matrix strategy. This reduces a 40-test run to 3–4 minutes. We also set up result recording for flaky test analysis.

Comparison of E2E Testing Tools

What Is Included in the Work (Deliverables)

1. Audit of current UI – identify key scenarios and stability points.
2. Framework setup – Cypress configuration, custom commands, fixtures.
3. Test coverage – 20 to 80 scenarios depending on complexity.
4. CI/CD integration – configs for GitHub Actions, GitLab CI, or Jenkins.
5. Documentation and training – instructions for running and updating tests.
6. Stability guarantee – two test runs on your environment and flaky test fixes.

Implementation Timeline and Cost

Starting from $2,000 for a typical 5-scenario coverage, the investment pays off through reduced regression time and increased release confidence.

Cost is calculated individually after project evaluation.

We guarantee test stability: use data-cy attributes, mock external APIs via cy.intercept(), and avoid sleep(). This makes tests deterministic and reduces flaky runs. As a result, you get reliable coverage that pays off through release stability and reduced regression time. Our experience: over 5 years and 30+ projects with E2E testing on Cypress.

Contact us for a consultation. We'll assess scope, timeline, and start implementation. Order E2E test implementation today – it will pay off with release stability and team peace of mind.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.