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.


Cypress Reports
When Cypress tests run in headless mode (npx cypress run) , the default reporting is quite limited. You typically get: terminal output screenshots for failures videos (if enabled) While useful, this makes debugging difficult in larger test suites or CI pipelines because there is no clear HTML dashboard summarizing test results. To solve this, Cypress supports custom reporters . Official documentation: https://docs.cypress.io/app/tooling/reporters Why Use Custom Reporters Cus
16 hours ago2 min read


Data-Driven Testing in Cypress
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
18 hours ago2 min read


Test Data in Cypress with Faker
Hard-coded test data works for small demos, but it quickly becomes a problem in real test suites. Using the same values repeatedly creates unrealistic scenarios and can cause conflicts when tests create or manipulate data. A better approach is to generate dynamic test data using a library like Faker . Why Hard-Coded Test Data Is a Problem Example of common hardcoded test data: "Test article" "John Doe" "Lorem ipsum" Problems with this approach: Tests always use the same valu
3 days ago2 min read


Cypress Test Retries
UI automation is naturally flaky. Even well-written tests may occasionally fail due to timing issues, environment instability, or application state problems. A test might: pass 10 times fail once pass again on the next run This creates noise in CI pipelines and can break the expectation of a 100% passing test suite . Cypress provides a built-in retry mechanism that automatically reruns failed tests before marking them as failed. Why Retries Exist Retries help stabilize test
3 days ago2 min read


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


NPM Scripts for Cypress
Typing full Cypress CLI commands every time gets old fast. Instead of this: npx cypress run --spec "cypress/e2e/firstTest.cy.js"npx cypress run --spec "cypress/e2e/firstTest.cy.js" --browser firefox Create reusable NPM scripts once — then just run: npm run cypress:smoke-firefox Cleaner. Faster. Better for CI. Why Use NPM Scripts? Avoid repeating long terminal commands Standardize execution across the team Simplify CI/CD pipelines Centralize configuration in one place (package
Mar 22 min read
bottom of page