Cursor testing

E2E Tests Timing Out in Cursor-Generated Test Suites

End-to-end tests generated by Cursor using Playwright, Cypress, or Selenium time out during execution. Tests hang waiting for elements that never appear, pages that never load, or network requests that never complete. The tests work sometimes but fail intermittently, making your test suite unreliable and CI pipelines unpredictable.

E2E test flakiness is the number one reason teams abandon automated testing. Cursor generates tests that follow the happy path but don't account for the asynchronous, timing-dependent nature of real browser interactions. The AI writes selectors for elements that may not exist yet, clicks buttons before they're interactive, and asserts content that loads asynchronously.

The result is a test suite that passes locally (where the app is fast) but fails in CI (where resources are limited and the app is slower), or passes 80% of the time and fails randomly on the other 20%.

Error Messages You Might See

TimeoutError: Waiting for selector "button.submit" exceeded 30000ms TimeoutError: page.waitForNavigation: Timeout 30000ms exceeded Error: Element is not visible or not an HTMLElement CypressError: Timed out retrying after 4000ms: Expected to find element: '[data-cy=result]' Test timeout of 60000ms exceeded
TimeoutError: Waiting for selector "button.submit" exceeded 30000msTimeoutError: page.waitForNavigation: Timeout 30000ms exceededError: Element is not visible or not an HTMLElementCypressError: Timed out retrying after 4000ms: Expected to find element: '[data-cy=result]'Test timeout of 60000ms exceeded

Common Causes

  • Static waits instead of dynamic waits — Cursor uses await page.waitForTimeout(3000) instead of waiting for specific elements or conditions, which is both slow and unreliable
  • Fragile CSS selectors — Tests use selectors like .sc-bdfBwQ.iQNHGt (auto-generated class names) that change every build, or deeply nested selectors that break with minor DOM changes
  • Missing API/network wait — The test clicks a submit button and immediately checks for a success message, without waiting for the API request to complete
  • Element not interactable — The test tries to click an element that's rendered but covered by a modal, loading overlay, or tooltip
  • CI environment is slower — Tests assume fast load times from local development. CI runners have less CPU/memory, making everything slower and timing-dependent tests fail
  • Navigation not awaited — The test clicks a link that triggers navigation but checks for content before the new page loads

How to Fix It

  1. Use data-testid attributes — Add data-testid="submit-button" to important elements and select with page.getByTestId('submit-button'). These are stable across builds and style changes
  2. Wait for specific conditions, not time — Replace waitForTimeout with await page.waitForSelector('[data-testid="success-message"]') or Playwright's auto-waiting assertions like await expect(page.getByText('Success')).toBeVisible()
  3. Wait for network idle after actions — Use await page.waitForLoadState('networkidle') or await page.waitForResponse(url => url.includes('/api/submit')) after form submissions
  4. Increase default timeout for CI — Set timeout: 60000 in your Playwright/Cypress config for CI environments while keeping shorter timeouts locally
  5. Use Playwright's built-in auto-waiting — Playwright's click(), fill(), and expect() methods auto-wait for elements to be visible and interactive. Use these instead of manual waits
  6. Add retry logic for flaky assertions — Use Playwright's expect().toBeVisible({ timeout: 10000 }) or Cypress's built-in retry-ability to handle timing variations

Real developers can help you.

MFox MFox Full-stack professional senior engineer (15+years). Extensive experience in software development, qa, and IP networking. Luca Liberati Luca Liberati I work on monoliths and microservices, backends and frontends, manage K8s clusters and love to design apps architecture rayush33 rayush33 JavaScript (React.js, React Native, Node.js) Developer with demonstrated industry experience of 4+ years, actively looking for opportunities to hone my skills as well as help small-scale business owners with solutions to technical problems Kingsley Omage Kingsley Omage Fullstack software engineer passionate about AI Agents, blockchain, LLMs. Matt Butler Matt Butler Software Engineer @ AWS Victor Denisov Victor Denisov Developer Matthew Butler Matthew Butler Systems Development Engineer @ Amazon Web Services Yovel Cohen Yovel Cohen I got a lot of experience in building Long-horizon AI Agents in production, Backend apps that scale to millions of users and frontend knowledge as well. Franck Plazanet Franck Plazanet I am a Strategic Engineering Leader with over 8 years of experience building high-availability enterprise systems and scaling high-performing technical teams. My focus is on bridging the gap between complex technology and business growth. Core Expertise: 🚀 Leadership: Managing and coaching teams of 15+ engineers, fostering a culture of accountability and continuous improvement. 🏗️ Architecture: Enterprise Core Systems, Multi-system Integration (ERP/API/ETL), and Core Database Structure. ☁️ Cloud & Scale: AWS Expert; architected systems handling 10B+ monthly requests and managing 100k+ SKUs. 📈 Business Impact: Aligning tech strategy with P&L goals to drive $70k+ in monthly recurring revenue. I thrive on "out-of-the-box" thinking to solve complex technical bottlenecks and am always looking for ways to use automation to improve business productivity. Daniel Vázquez Daniel Vázquez Software Engineer with over 10 years of experience on Startups, Government, big tech industry & consulting.

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help

Frequently Asked Questions

How do I make E2E tests less flaky?

Three key practices: 1) Never use fixed timeouts (waitForTimeout), always wait for specific conditions. 2) Use stable selectors (data-testid) instead of CSS classes or XPath. 3) Wait for network requests to complete before asserting results. Also run tests in a consistent environment with controlled test data.

Should I run E2E tests in CI on every commit?

Run fast unit tests on every commit. Run E2E tests on pull requests and before deployments. E2E tests are slow and resource-intensive, so running them on every commit slows down the feedback loop. Use parallelization and test sharding to speed them up when you do run them.

Related Cursor Issues

Can't fix it yourself?
Real developers can help.

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help