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.

Antriksh Narang Antriksh Narang 5 years+ Experienced Dev (Specially in Web Development), can help in python, javascript, react, next.js and full stack web dev technologies. Milan Surelia Milan Surelia Milan Surelia is a Mobile App Developer with 5+ years of experience crafting scalable, cross-platform apps at 7Span and Meticha. At 7Span, he engineers feature-rich Flutter apps with smooth performance and modern UI. As the Co-Founder of Meticha, he builds open-source tools and developer-focused products that solve real-world problems. Expertise: 💡 Developing cross-platform apps using Flutter, Dart, and Jetpack Compose for Android, iOS, and Web. 🖋️ Sharing insights through technical writing, blogging, and open-source contributions. 🤝 Collaborating closely with designers, PMs, and developers to build seamless mobile experiences. Notable Achievements: 🎯 Revamped the Vepaar app into Vepaar Store & CRM with a 2x performance boost and smoother UX. 🚀 Launched Compose101 — a Jetpack Compose starter kit to speed up Android development. 🌟 Open source contributions on Github & StackOverflow for Flutter & Dart 🎖️ Worked on improving app performance and user experience with smart solutions. Milan is always happy to connect, work on new ideas, and explore the latest in technology. Kingsley Omage Kingsley Omage Fullstack software engineer passionate about AI Agents, blockchain, LLMs. Rudra Bhikadiya Rudra Bhikadiya I build and fix web apps across Next.js, Node.js, and DBs. Comfortable jumping into messy code, broken APIs, and mysterious bugs. If your project works in theory but not in reality, I help close that gap. Jen Jacobsen Jen Jacobsen I’m a Full-Stack Developer with over 10 years of experience building modern web and mobile applications. I enjoy working across the full product lifecycle — turning ideas into real, well-built products that are intuitive for users and scalable for businesses. I particularly enjoy building mobile apps, modern web platforms, and solving complex technical problems in a way that keeps systems clean, reliable, and easy to maintain. Jacek Rozanski Jacek Rozanski Senior PHP/Symfony developer and DevOps engineer with 20+ years of professional experience, running opcode.pl (web development agency, est. 2004). Day job: I'm the sole backend developer at merketing company where I own and maintain 11 PHP/Symfony microservices on AWS (ECS Fargate, RDS, S3, CloudFront), handle the full CI/CD pipeline (Bitbucket Pipelines, Docker), and manage monitoring with Sentry and CloudWatch. These services handle high request volumes in production every month. What I bring to AI-built apps: - I audit and fix security issues (OWASP methodology), performance bottlenecks, and architectural problems in codebases generated by Cursor, Claude Code, Lovable, Bolt, and v0 - I refactor AI-generated prototypes into production-grade applications with proper error handling, testing, and clean architecture (SOLID, DDD, hexagonal architecture) - I set up the infrastructure AI tools don't touch: AWS hosting, CI/CD pipelines, automated deployments, database optimization, monitoring, and alerting - I integrate external services: payment providers, email systems, partner APIs, SSO/auth Tech stack: PHP 8.x, Symfony, React, Next.js, PostgreSQL, MySQL, Docker, AWS (ECS, RDS, S3, SQS/SNS, CloudFront), Terraform, Supabase. I also use AI tools daily (Claude Code, Cursor) in my own workflow, so I understand both the strengths and the gaps in AI-generated code. Based in Poland (CET timezone). Available for async work and calls during EU/US business hours. Pratik Pratik SWE with 15+ years of experience building and maintaining web apps and extensive BE infrastructure Prakash Prajapati Prakash Prajapati I’m a Senior Python Developer specializing in building secure, scalable, and highly available systems. I work primarily with Python, Django, FastAPI, Docker, PostgreSQL, and modern AI tooling such as PydanticAI, focusing on clean architecture, strong design principles, and reliable DevOps practices. I enjoy solving complex engineering problems and designing systems that are maintainable, resilient, and built to scale. zipking zipking I am a technologist and product builder dedicated to creating high-impact solutions at the intersection of AI and specialized markets. Currently, I am focused on PropScan (EstateGuard), an AI-driven SaaS platform tailored for the Japanese real estate industry, and exploring the potential of Archify. As an INFJ-T, I approach development with a "systems-thinking" mindset—balancing technical precision with a deep understanding of user needs. I particularly enjoy the challenge of architecting Vertical AI SaaS and optimizing Small Language Models (SLMs) to solve specific, real-world business problems. Whether I'm in a CTO-level leadership role or hands-on with the code, I thrive on building tools that turn complex data into actionable value. Sage Fulcher Sage Fulcher Hey I'm Sage! Im a Boston area software engineer who grew up in South Florida. Ive worked at a ton of cool places like a telehealth kidney care startup that took part in a billion dollar merger (Cricket health/Interwell health), a boutique design agency where I got to work on a ton of exciting startups including a photography education app, a collegiate Esports league and more (Philosophie), a data analytics as a service startup in Cambridge (MA) as well as at Phillips and MIT Lincoln Lab where I designed and developed novel network security visualizations and analytics. I've been writing code and furiously devoted to using computers to make people’s lives easier for about 17 years. My degree is in making computers make pretty lights and sounds. Outside of work I love hip hop, the Celtics, professional wrestling, magic the gathering, photography, drumming, and guitars (both making and playing them)

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