--- title: Better world by better software | daily.dev description: When testing apps that load data, naive tests that only check the happy path can be slow and uninformative when they fail. By explicitly handling all possible... canonical: https://daily.dev/posts/better-world-by-better-software-afxfv6uwc twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Better world by better software | daily.dev og:description: When testing apps that load data, naive tests that only check the happy path can be slow and uninformative when they fail. By explicitly handling all possible... og:url: https://daily.dev/posts/better-world-by-better-software-afxfv6uwc og:image: https://api.daily.dev/og/posts/AfxFv6UWC.png og:image:alt: Better world by better software og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Better world by better software **[Gleb Bahmutov](https://daily.dev/sources/glebbahmutov)** · 4 min read · 0 upvotes · 0 comments ## Summary When testing apps that load data, naive tests that only check the happy path can be slow and uninformative when they fail. By explicitly handling all possible app states (success, empty, error) using the cypress-if plugin's cy.depends command, tests can fail immediately with clear messages instead of waiting for a timeout. For transient failures like empty data, the cypress-recurse plugin enables in-place page reloads rather than full test retries, making tests faster and more resilient while still providing accurate failure diagnostics. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I make my Cypress end-to-end tests fail faster when the app shows an error instead of waiting for the full timeout? Use the cy.depends command from the cypress-if plugin to check for error or empty-state elements explicitly and fail immediately when found, rather than letting cy.get retry until the default timeout (e.g. 5 seconds) elapses. This can cut a failing test's run time to around 122ms and produces a clear message like 'Items failed to load' instead of a generic 'element not found' error. _daily.dev surfaces practical Cypress patterns for developers chasing down flaky end-to-end tests._ ### What is the difference between Cypress test retries and the cypress-recurse plugin for handling flaky tests? Cypress's built-in test retries rerun an entire test from the beginning whenever it fails, which is wasteful for long tests (e.g. two minutes) that hit small hiccups like an empty data list. The cypress-recurse plugin allows in-place retries of just a specific step, such as reloading the page only when zero items are found, while still letting a genuine error state trigger a full test retry. _developers weighing test-retry strategies can find hands-on comparisons like this via daily.dev._ ## Similar posts on daily.dev - [AI self-healing in Cypress: reliable tests with full visibility](https://daily.dev/posts/ai-self-healing-in-cypress-reliable-tests-with-full-visibility-x5nfkkzao) · cypress · 0 upvotes · 0 comments - [Cypress Cloud Test Triage Using AI](https://daily.dev/posts/cypress-cloud-test-triage-using-ai-32djfmhgs) · Gleb Bahmutov · 0 upvotes · 1 comments - [Form Fatigue? Let Cypress and Faker.js Do the Dirty Work](https://daily.dev/posts/form-fatigue-let-cypress-and-faker-js-do-the-dirty-work-qreqpqy2m) · Atomic Spin · 0 upvotes · 0 comments --- Tags: [#testing](https://daily.dev/tags/testing), [#cypress](https://daily.dev/tags/cypress) [View this post on daily.dev](https://daily.dev/posts/better-world-by-better-software-afxfv6uwc) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Better world by better software","url":"https://daily.dev/posts/better-world-by-better-software-afxfv6uwc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/better-world-by-better-software-afxfv6uwc"},"datePublished":"2026-07-28T14:52:36.673Z","dateModified":"2026-09-13T21:32:11.843Z","description":"When testing apps that load data, naive tests that only check the happy path can be slow and uninformative when they fail. By explicitly handling all possible...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1bd31fa8150b270bb129c1b926f2a8a6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1bd31fa8150b270bb129c1b926f2a8a6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Gleb Bahmutov","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Gleb Bahmutov","logo":"https://media.daily.dev/image/upload/s--TzkdP-7a--/f_auto,q_auto/v1780213676/logos/glebbahmutov?_a=BAMAMiWQ0","url":"https://daily.dev/sources/glebbahmutov"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/better-world-by-better-software-afxfv6uwc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"testing,cypress","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Gleb Bahmutov","item":"https://daily.dev/sources/glebbahmutov"},{"@type":"ListItem","position":3,"name":"Better world by better software"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/better-world-by-better-software-afxfv6uwc#faq","mainEntity":[{"@type":"Question","name":"How do I make my Cypress end-to-end tests fail faster when the app shows an error instead of waiting for the full timeout?","acceptedAnswer":{"@type":"Answer","text":"Use the cy.depends command from the cypress-if plugin to check for error or empty-state elements explicitly and fail immediately when found, rather than letting cy.get retry until the default timeout (e.g. 5 seconds) elapses. This can cut a failing test's run time to around 122ms and produces a clear message like 'Items failed to load' instead of a generic 'element not found' error. daily.dev surfaces practical Cypress patterns for developers chasing down flaky end-to-end tests."}},{"@type":"Question","name":"What is the difference between Cypress test retries and the cypress-recurse plugin for handling flaky tests?","acceptedAnswer":{"@type":"Answer","text":"Cypress's built-in test retries rerun an entire test from the beginning whenever it fails, which is wasteful for long tests (e.g. two minutes) that hit small hiccups like an empty data list. The cypress-recurse plugin allows in-place retries of just a specific step, such as reloading the page only when zero items are found, while still letting a genuine error state trigger a full test retry. developers weighing test-retry strategies can find hands-on comparisons like this via daily.dev."}}]} ```