Digital Shelf

Data-driven testing means running the same test multiple times with different input data . Instead of writing several almost identical tests, a single test can iterate through a dataset and validate different scenarios. This approach is especially useful for: form validation boundary testing error message verification repetitive input testing It reduces duplicated code and makes tests easier to maintain. Example Scenario – Username Validation In this example the Conduit appli

Hardcoding credentials, API URLs, or environment-specific values in tests is not ideal.It makes tests harder to maintain and can expose sensitive information. Cypress provides several ways to manage environment variables , allowing tests to run across different environments (dev, QA, staging, production) without changing the test code. This page is a reference for the most common approaches. Why Use Environment Variables? Environment variables help: Avoid hardcoding credenti

Typing email + password in every test is slow and noisy. Cypress can skip the login screen completely by grabbing a token via API and placing it into localStorage before the app loads . This is a practical reference showing the before vs after , plus a reusable custom command. Why This Helps UI login usually costs ~8 seconds per test run (open page, fill fields, submit, wait UI). Token-based login can cut it to ~5 seconds because it avoids the whole form flow. Tests become cl

Cypress can run full end-to-end API workflows without opening the browser UI. It’s fast and stable, and it’s a good skill to understand. That said, for serious API testing at scale , Cypress is not the best tool. It works, but it gets clunky quickly. This post shows the approach and also explains where it makes sense (and where it doesn’t). What “E2E API Test” Means Here This type of test validates a full data lifecycle using only HTTP calls: Create auth token POST a new art

UI flows are great for end-to-end confidence, but they’re slow when used just to “prepare data”. A common Cypress pattern is: create the test data via API run the real scenario via UI validate the result in the UI (and optionally via API) This page is a reference for that workflow. Why cy.request() is Useful cy.request() sends HTTP calls directly to the backend. It’s perfect for: creating articles/users/orders fast avoiding flaky UI setup steps keeping tests focused on the th

Modern applications load content asynchronously through APIs.If a test does not properly wait for those API responses, race conditions appear. This reference explains how to correctly wait for browser API calls in Cypress and prevent flakiness in dynamic applications. The Problem: Asynchronous Content When UI content depends on /articles API response, Cypress may assert before data is fully loaded. This approach is flaky: Why it fails: .invoke('text') captures text immediatel