top of page
Digital Shelf
It’s more of a personal collection—random things I come across, resources worth remembering, and thoughts I might want to come back to later. Just a place to keep track of it all.


Environment Variables in Cypress
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
6 days ago2 min read


Skip Login With Saved Token in Cypress
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
Feb 281 min read


E2E API Testing in Cypress
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
Feb 212 min read


Test Data with API for Cypress Test
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
Feb 212 min read


Waiting for Browser API Calls & Cypress
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
Feb 171 min read


API Mocking In Cypress
API mocking is a powerful Cypress feature that allows tests to run faster, more reliably, and independently of backend data. This page serves as a hands-on reference for how API interception works in Cypress. Cypress API Interception Overview Cypress provides the cy.intercept() command to intercept browser API calls and optionally return mock responses. There are three common ways to define an intercept: URL + response Method + URL + response (recommended for clarity) Route
Feb 112 min read
bottom of page