Forem: mohamed Said Ibrahim

The Complete Guide to Testing React & Next.js Applications with Cypress

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:56:02 +0000

The Complete Guide to Testing React & Next.js Applications with Cypress

Why Cypress for React & Next.js Testing?

The Complete Guide to Testing React & Next.js Applications with Cypress

Why Cypress for React & Next.js Testing?

Modern web applications built with React and Next.js require robust testing to ensure UI consistency, functional reliability, and optimal performance. While tools like Jest and React Testing Library handle unit and integration tests, Cypress.io excels in end-to-end (E2E) testing, offering:

✅ Real-time reloading & debugging

✅ Automatic waiting for elements

✅ Network request control & mocking

✅ Cross-browser testing support

However, challenges like dynamic content, state management, and rendering issues can complicate testing. This guide covers best practices for testing React & Next.js apps with Cypress.

1. Setting Up Cypress for React & Next.js

Installation

npm install cypress --save-dev  
npx cypress open  # Launch Cypress

Folder Structure

/cypress

/e2e

- home.cy.js

- auth.cy.js

/fixtures

- mockUsers.json

/support

- commands.js

Configuring `cypress.config.js` for Next.js

const { defineConfig } = require('cypress');  

module.exports = defineConfig({  
  e2e: {  
    baseUrl: 'http://localhost:3000', // Next.js dev server  
    setupNodeEvents(on, config) {  
      // Plugins here  
    },  
  },  
});

The Complete Guide to Testing React & Next.js Applications with Cypress

2. Testing React Components with Cypress

Component Testing (Cypress + React)

Cypress supports component testing for isolated React component checks.

Install React Adapter:

npm install @cypress/react @cypress/webpack-dev-server --save-dev

Example: Testing a Counter Component

// Counter.js  
import { useState } from 'react';  

export default function Counter() {  
  const [count, setCount] = useState(0);  
  return (  
    <div>  
      <button onClick={() => setCount(count + 1)}>Increment</button>  
      <span data-testid="count">{count}</span>  
    </div>  
  );  
}  
// Counter.cy.js  
import Counter from './Counter';  
describe('Counter Component', () => {  
  it('increments count on click', () => {  
    cy.mount(<Counter />);  
    cy.get('button').click();  
    cy.get('[data-testid="count"]').should('have.text', '1');  
  });  
});

Key Benefits:

✔ Visual debugging in real-time

✔ Direct DOM interaction testing

✔ Works with hooks & context

3. Handling Dynamic Content & API Calls

Mocking API Responses

Cypress allows intercepting and stubbing API requests.

Example: Testing a User Dashboard

// UserDashboard.js (Fetches data dynamically)  
import { useEffect, useState } from 'react';  

export default function UserDashboard() {  
  const [users, setUsers] = useState([]);  
  useEffect(() => {  
    fetch('/api/users').then(res => res.json()).then(setUsers);  
  }, []);  
  return (  
    <ul>  
      {users.map(user => <li key\={user.id}>{user.name}</li>)}  
    </ul>  
  );  
}  
// UserDashboard.cy.js  
describe('User Dashboard', () => {  
  it('displays fetched users', () => {  
    cy.intercept('GET', '/api/users', { fixture: 'mockUsers.json' }).as('getUsers');  
    cy.mount(<UserDashboard />);  

    cy.wait('@getUsers');  
    cy.get('li').should('have.length', 3);  
  });  
});

Best Practices:

✔ Use cy.intercept() for API mocking

✔ Leverage fixtures (/cypress/fixtures) for mock data

✔ Test loading & error states

4. Solving Common React Testing Challenges

A. State Management Issues

Problem: Tests fail due to unexpected state changes.

Solution:

Reset state between tests (use beforeEach).
Use cy.wrap() for async state checks.

describe('Todo App', () => {  
  beforeEach(() => {  
    cy.mount(<TodoApp />);  
  });  

it('adds a new todo', () => {  
    cy.get('input').type('Buy milk');  
    cy.get('button').click();  
    cy.get('.todo-item').should('contain', 'Buy milk');  
  });  
});

B. Next.js Routing & SSR Challenges

Problem: Hydration errors in Next.js.

Solution:

✔ Use next-router-mock for testing

✔ Test SSR pages with cy.request()

// Testing a Next.js dynamic route  
describe('Blog Post Page', () => {  
  it('loads the correct post', () => {  
    cy.intercept('GET', '/api/posts/1', { fixture: 'post.json' }).as('getPost');  
    cy.visit('/posts/1'); // Dynamic route  
    cy.wait('@getPost');  
    cy.get('h1').should('contain', 'My First Post');  
  });  
});

C. Flaky Tests Due to Rendering Delays

Problem: Tests fail randomly due to slow renders.

Solution:

✔ Use cy.should() for assertions (retries automatically).

✔ Increase timeout if needed ({ timeout: 10000 }).

cy.get('[data-testid="loading"]').should('not.exist'); // Waits for loader to disappear

5. Advanced Cypress Strategies for React/Next.js

A. Visual Regression Testing

Use cypress-image-snapshot to detect UI changes.

npm install cypress-image-snapshot --save-dev

// cypress/support/commands.js  
import { addMatchImageSnapshotCommand } from 'cypress-image-snapshot/command';  
addMatchImageSnapshotCommand();  

// Usage  
cy.get('.header').matchImageSnapshot('header-component');

B. Running Tests in CI/CD (GitHub Actions Example)

name: Cypress Tests  
on: [push]  
jobs:  
  test:  
    runs-on: ubuntu-latest  
    steps:  
      - uses: actions/checkout@v3  
      - run: npm install  
      - run: npm run build  
      - run: npx cypress run --headless

C. Cross-Browser Testing

Run Cypress tests on Chrome, Firefox, Edge via:

npx cypress run --browser firefox

Final Checklist for React/Next.js Testing with Cypress

✅ Test components in isolation (Cypress Component Testing).

✅ Mock API calls with cy.intercept().

✅ Handle state & routing issues systematically.

✅ Use visual regression & CI/CD for scalability.

✅ Run cross-browser tests for full coverage.

Conclusion

Cypress is a powerful tool for testing React & Next.js applications, offering:

✔ Real-time debugging

✔ API mocking & dynamic content handling

✔ Solutions for state, routing, and flaky tests

By following these strategies, you can ensure UI consistency, functional reliability, and optimal performance in your apps.

🚀 Ready to supercharge your testing workflow? Start using Cypress today!

React #NextJS #Cypress #Testing #Automation #WebDev #FrontEnd

Have questions about testing React with Cypress? Ask below! 👇

By Mohamed Said Ibrahim on May 30, 2025.

Exported from Medium on October 2, 2025.

Core Technical Topics to Master in Cypress for Effective E2E Testing

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:53:11 +0000

Core Technical Topics to Master in Cypress for Effective E2E Testing

End-to-end (E2E) testing is a crucial part of modern web development, ensuring that applications work as expected from the user’s…

Core Technical Topics to Master in Cypress for Effective E2E Testing

End-to-end (E2E) testing is a crucial part of modern web development, ensuring that applications work as expected from the user’s perspective. Cypress has emerged as a leading tool for E2E testing due to its speed, reliability, and developer-friendly features.

In this guide, we’ll explore the core technical topics you need to master in Cypress, including writing tests, best practices, and integrating Cypress into CI/CD pipelines.

1. Writing Cypress Tests (Selectors, Commands, Assertions)

Selectors

Cypress provides multiple ways to select DOM elements:

cy.get() – Uses CSS selectors (e.g., cy.get('.btn')).
cy.contains() – Finds elements by text content (e.g., cy.contains('Submit')).
data-* attributes – Best practice for stable selectors (e.g., cy.get('[data-test="login-button"]')).

Commands & Assertions

Cypress chains commands for readability:

cy.visit('/login')    
  .get('\[data-test="username"\]').type('testuser')    
  .get('\[data-test="password"\]').type('password123')    
  .get('\[data-test="submit"\]').click()    
  .url().should('include', '/dashboard')

Common assertions:

.should('be.visible') – Checks element visibility.
.should('have.text', 'Success') – Verifies text content.

Core Technical Topics to Master in Cypress for Effective E2E Testing

2. Page Object Model (POM) in Cypress

The Page Object Model (POM) improves test maintainability by encapsulating page logic:

// pages/LoginPage.js    
class LoginPage {    
  visit() {    
    cy.visit('/login');    
  }    

fillUsername(username) {    
    cy.get('\[data-test="username"\]').type(username);    
  }    
  submit() {    
    cy.get('\[data-test="submit"\]').click();    
  }    
}    
export default new LoginPage();

Usage in Tests:

import LoginPage from '../pages/LoginPage';    

describe('Login Test', () => {    
  it('logs in successfully', () => {    
    LoginPage.visit();    
    LoginPage.fillUsername('testuser');    
    LoginPage.submit();    
    cy.url().should('include', '/dashboard');    
  });    
});

Benefits:

✔ Reduces code duplication

✔ Easier maintenance

✔ Clear separation of concerns

3. Handling API Requests & Network Interception

`cy.request()` for API Testing

Cypress can directly call APIs:

cy.request('POST', '/api/login', {    
  username: 'testuser',    
  password: 'password123'    
}).then((response) => {    
  expect(response.status).to.eq(200);    
});

`cy.intercept()` for Mocking & Stubbing

Intercept and mock API calls:

cy.intercept('GET', '/api/users', {    
  fixture: 'users.json'    
}).as('getUsers');    

cy.visit('/dashboard');    
cy.wait('@getUsers').then((interception) => {    
  expect(interception.response.body).to.have.length(3);    
});

4. Running Tests on Different Viewports/Devices

Cypress supports responsive testing with cy.viewport():

describe('Responsive Test', () => {    
  it('displays correctly on mobile', () => {    
    cy.viewport('iphone-6');    
    cy.visit('/');    
    cy.get('.navbar-toggle').should('be.visible');    
  });    
});

Common Viewports:

cy.viewport(1920, 1080) (Desktop)
cy.viewport('ipad-2') (Tablet)
cy.viewport('samsung-s10') (Mobile)

5. Handling Test Flakiness & Retries

Causes of Flakiness:

Dynamic content loading
Unstable network requests
Race conditions

Solutions:

✔ Use cy.wait() with aliased requests.

✔ Implement retries in cypress.json:

{    
  "retries": {    
    "runMode": 2,    
    "openMode": 0    
  }    
}

✔ Avoid cy.wait(5000) (prefer cy.get().should()).

6. Using Cypress with GitHub/GitLab CI

GitHub Actions Example:

name: Cypress Tests    
on: [push]    
jobs:    
  test:    
    runs-on: ubuntu-latest    
    steps:    
      - uses: actions/checkout@v2    
      - run: npm install    
      - run: npx cypress run --headless

### GitLab CI Example:

stages:    
  - test    

e2e:    
  stage: test    
  image: cypress/base:14    
  script:    
    - npm install    
    - npx cypress run --headless

Key CI Optimizations:

Parallelization (--parallel)
Caching dependencies for faster runs
Artifact storage for test videos/screenshots

Example Question: Structuring Cypress Tests for a Large React App

Best Practices:

✅ Modularize tests (e.g., auth, dashboard, settings).

✅ Use POM for reusable page interactions.

✅ Mock APIs to avoid backend dependencies.

✅ Separate specs by feature (e.g., login.spec.js, checkout.spec.js).

✅ Leverage custom commands for repetitive actions.

Example Structure:

/cypress

/fixtures

- users.json

/integration

/auth

- login.spec.js

- signup.spec.js

/dashboard

- overview.spec.js

/pages

- LoginPage.js

- DashboardPage.js

/support

- commands.js

Conclusion

Mastering Cypress involves understanding:

✔ Writing efficient tests (selectors, assertions).

✔ Using POM for scalability.

✔ Handling APIs & network calls.

✔ Responsive testing across devices.

✔ Reducing flakiness with retries.

✔ CI/CD integration for automated testing.

By applying these techniques, you can build reliable, maintainable, and fast E2E test suites for any web application.

🚀 Ready to supercharge your testing workflow? Start implementing these Cypress best practices today!

Cypress #Testing #QA #Automation #WebDevelopment #JavaScript #ContinuousIntegration

Would you like a deeper dive into any of these topics? Let me know in the comments! 👇

By Mohamed Said Ibrahim on May 30, 2025.

Exported from Medium on October 2, 2025.

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:47:49 +0000

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

The build is red. Again.

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

The build is red. Again.

As a QA engineer or SDET, this is a familiar sight. While failed tests are often seen as roadblocks, they are, in fact, invaluable feedback loops. They tell us where our application breaks, where our assumptions are wrong, or where our tests need improvement. But sifting through dozens, or even hundreds, of failed test logs after a large Cypress run can be a daunting, time-consuming, and often frustrating task.

“Was that a flaky element visibility issue, or did the API truly return a 500 error?” “Is this a critical login bug that blocks everything, or just a minor UI glitch?”

Without structured analysis, these questions lead to manual digging, delayed debugging, and slower releases.

This article will demystify the most common Cypress test failure reasons (errors and exceptions), providing clear explanations and actionable insights. More importantly, we’ll introduce a powerful Node.js script, generate_failed_tests_report.js, that automates the analysis of your Cypress Mochawesome reports, transforming chaotic red logs into organized, prioritized, and actionable CSV reports.

Let’s turn that frustrating red into a clear path forward!

The Unavoidab`node generate_failed_tests_report.js`le Truth: Understanding Common Cypress Test Failures

Every Cypress test failure, whether an AssertionError, TypeError, or CypressError, tells a story. Learning to read these stories efficiently is paramount for robust test automation.

We’ve categorized and prioritized these failures just as our script does, to give you a framework for quick triage.

🔴 Critical Priority Failures: Stop Everything!

These errors typically indicate fundamental issues that prevent significant portions of your test suite, or even the entire application, from functioning. Address these first.

1. **TypeError** / **TypeError (Runtime)**
What it is: A JavaScript error that occurs when an operation is performed on a value that is not of the expected type (e.g., trying to call a method on undefined or null).
Common Causes in Cypress:
Element Not Found (Indirectly): You try to chain a command like .click() or .type() onto a cy.get() that yielded no element. While Cypress's retry mechanism is robust, if the element genuinely doesn't appear, the subsequent chained command on a non-existent element might throw a TypeError.
Incorrect Page Object Model (POM) Usage: Calling a method on an imported page object that hasn’t been properly initialized or defined.
Custom Command or Utility Function Issues: Errors within your custom Cypress commands or helper functions, indicating a variable is not what it’s expected to be.
How to Debug/Fix:
Verify element existence and visibility before interaction (Cypress often handles this, but explicit cy.should('exist') or cy.should('be.visible') can clarify intention).
Check for correct imports and instantiation of your POMs or utility classes.
Inspect err.estack for the exact line number in your test code or custom command.
Example Messages: TypeError: cy.verifyAnyCellInTable is not a function, someVariable.someMethod is not a function
2. **ReferenceError** / **ReferenceError (Runtime)**
What it is: A JavaScript error that occurs when a variable or function is referenced that has not been declared or is out of scope.
Common Causes in Cypress:
Undeclared Variables: Using a variable name that hasn’t been defined with const, let, or var.
Typographical Errors: Simple typos in variable or function names.
Missing Imports: Forgetting to import a required module or function from another file.
How to Debug/Fix:
Double-check variable and function spellings.
Ensure all necessary modules are correctly imported at the top of your test file or support file.
Check the scope of your variables.
Example Messages: ReferenceError: trimText is not defined, myFunction is not defined
3. **Before Each Hook Failure**
What it is: An error occurring within a before() or beforeEach() Cypress hook. Since these hooks are crucial for setting up the test environment (e.g., logging in, visiting a page), their failure often prevents all subsequent tests in that suite from running.
Common Causes in Cypress:
Login Failures: Incorrect credentials, login form changes, API authentication issues.
Initial Page Load Issues: cy.visit() failing due to incorrect URL, application not running, or network problems.
Data Setup Errors: Problems with cy.fixture() to load test data, or cy.intercept() not intercepting expected requests.
Critical Element Missing: An element that’s expected to be present on page load (e.g., a dashboard header) is not found.
How to Debug/Fix:
Isolate the hook and debug it independently.
Verify login credentials and flow manually.
Ensure the application is running and accessible at the baseUrl or cy.visit() URL.
Check network requests (using Cypress’s network tab or cy.intercept()) during the hook.
Example Message: Because this error occurred during abefore eachhook we are skipping the remaining tests in the current suite:

🟠 High Priority Failures: Application Under Test isn’t Behaving!

These are often direct indicators of bugs or regressions in your application’s functionality or UI. They require immediate attention as they represent user-facing issues.

4. **AssertionError**
What it is: The most common type of failure, indicating that an expect() assertion (e.g., .should()) failed. This means the actual state of the application did not match the expected state. Cypress's built-in retry-ability means these assertions are attempted multiple times before failing, usually culminating in a "Timed out retrying after Xms" message.
Common Causes in Cypress:
Element Not Found (**Expected to find element: X, but never found it.**): The DOM element specified by your selector (tbody tr, [data-testid=table_button_edit], button.export, etc.) was not present on the page within the given timeout. This can be due to:
Element truly missing or removed.
Incorrect CSS selector.
Element not yet rendered by the application (race condition).
Content/Value Mismatch (**expected 'X' to be 'Y'**, **expected 'X' to match 'Y'**, **expected 500 to equal 200**): The text content, attribute value, or API response status is not what the test expected.
Visibility Issues (**expected 'X' to be 'visible'**): An element exists in the DOM but is not visually displayed (e.g., display: none, opacity: 0, off-screen, or covered by another element).
How to Debug/Fix:
For Element Not Found:
Inspect the DOM for the correct selector.
Add cy.wait() for an API call or cy.get().should('be.visible') before interaction to allow elements to render.
Confirm application data or state that dictates element presence.
For Content Mismatch: Verify the expected content/value against the actual application behavior.
For Visibility: Check CSS properties, overlaying elements, or asynchronous rendering.
Example Messages:
AssertionError: Timed out retrying after 30000ms: Expected to find element:tbody tr, but never found it.
AssertionError: expected 'https://auth.microtecstage.com/Account/Login?returnUrl=...
AssertionError: expected '<label.form-label.paragraph_b18>' to be 'visible'
5. **UI Visibility Error**
What it is: A custom error (likely thrown by your own utility functions or assertions) indicating that a specific UI component, like a table, was expected to be visible but was not.
Common Causes in Cypress: Similar to AssertionError visibility issues, but specific to components you've encapsulated with custom checks.
How to Debug/Fix: Investigate the specific component’s rendering and styling.

🟡 Medium Priority Failures: Interactivity & Timing Issues

These errors often highlight issues with how Cypress interacts with a dynamic application, or subtle timing problems. They can be indicative of flaky tests and may require adjustments to test logic or waiting strategies.

6. **CypressError**
What it is: A general error thrown directly by Cypress, indicating an issue with a Cypress command or its internal state.
Common Causes & Specific Details:
**Cypress Visit Load Failure** (**cy.visit()** failed trying to load): The browser couldn't load the specified URL. This might mean the app is down, the URL is wrong, or a severe network issue.
**Cypress Click Stale Element** (**cy.click()** failed because the page updated): An element that Cypress targeted for clicking was re-rendered or removed from the DOM between when Cypress found it and when it tried to click it. This is a common race condition in highly dynamic SPAs.
**Cypress Click Covered Element** (**cy.click()** failed because this element is being covered by another element): Cypress detects that another DOM element is obstructing the element it's trying to click, mimicking real user behavior (users can't click through overlays).
**Cypress Wait Request Timeout (cy.wait() timed out waiting... No request ever occurred.):** Acy.wait()` alias was set for a specific network request, but the application never sent that request within the timeout. This often means the action that was supposed to trigger the request failed, or the app's network logic changed.
**Cypress Match Argument Invalid** (**match** requires its argument be a **RegExp**): Occurs when a command or assertion expecting a regular expression (e.g., cy.contains(/text/i)) receives an invalid argument.
**Cypress Scroll Multi-Element (cy.scrollIntoView() can only be used to scroll to 1 element):** Your selector forcy.scrollIntoView()` matched multiple elements, but the command expects a single element to scroll to.
How to Debug/Fix:
For **cy.visit()**: Check application server status, network connectivity, and baseUrl configuration.
For **cy.click()** (Stale/Covered):
Add more specific waits before interaction (e.g., cy.get('element').should('be.visible').click()).
Ensure modals or loading spinners are dismissed before attempting clicks.
Rethink timing if DOM changes are happening rapidly.
For **cy.wait()** timeouts: Verify the network request is indeed sent by the application. Add cy.intercept() logs to confirm the request pattern.
For argument errors: Correct the syntax of your arguments.

⚫ Other/Unknown Priority Failures

**Other/Unknown** / **Unclassified Error Detail**:
Explanation: This category catches any error message that doesn’t fit the predefined classification rules. It’s a catch-all for less common issues or errors you haven’t yet categorized.
How to Debug/Fix: These errors require manual inspection of the err_message and err_estack to understand their nature. If a new pattern emerges, you can add it to the ERROR_CATEGORIZATION_RULES in the script to categorize it automatically in future runs.

Beyond the Red: Introducing the Cypress Failed Tests Report Generator

Understanding errors is one thing; efficiently analyzing them across hundreds of tests is another. Manually sifting through Mochawesome JSON files is tedious and prone to missing critical insights. This is where the generate_failed_tests_report.js script becomes an invaluable asset for any Cypress automation suite.

This Node.js script automates the process of parsing your merged Mochawesome JSON reports and outputs a clean, structured CSV file.

The Objective of `generate_failed_tests_report.js`

The script’s core purpose is to provide an actionable, summarized view of failed tests. Instead of just knowing a test failed, it tells you:

Which test file and suite failed.
What type of error occurred (FailingCategory).
How critical the error is (Priority).
What specific detail about the error is most relevant (FailingCategoryDetail).
The raw error message and stack trace for in-depth debugging.

This transforms scattered failure data into a focused report that empowers faster triage and more effective debugging cycles.

How It Works: A Deep Dive into the Script’s Anatomy

The generate_failed_tests_report.js script is built on a logical flow designed for efficiency and customization:

Reading the Merged Report (**INPUT_JSON_FILE**): The script starts by loading your mergedReport.json file. This file is typically generated by merging individual JSON reports created by Mochawesome after each Cypress spec run. fs-extra is used for robust file system operations.
Recursive Test Traversal: Cypress tests can be nested deeply within describe blocks. The script smartly navigates this hierarchy. It iterates through the top-level results (each representing a spec file) and then recursively dives into any nested suites arrays, ensuring every test object is inspected.
The Power of **ERROR_CATEGORIZATION_RULES**: This constant array is the heart of the script's intelligence. It's a collection of rules, each defined by:

**regex**: A regular expression to broadly match a type of error message (e.g., ^AssertionError:).
**category**: The high-level classification (e.g., AssertionError).
**priority**: The assigned severity (e.g., High).
**details**: A nested array of more granular rules, each with its own regex and detailMessage. This is where the magic happens for FailingCategoryDetail.

The rules are ordered by precedence: more specific or critical errors are listed first.

**4. getErrorCategoryAndPriority(errorMessage)** Function: This pivotal function is responsible for the categorization. When a failed test's error message is passed to it:

It first cleans the message (removes ANSI codes, trims whitespace).
It then iterates through ERROR_CATEGORIZATION_RULES. The first top-level regex that matches the error message determines the category and priority.
Once a category rule is matched, it then iterates through that rule’s *details* array. Again, the first detail.regex that matches the error message determines the specific detailMessage.
Dynamic Detail Extraction (Capture Groups): Crucially, if the detail.regex contains capture groups (parts in parentheses like ([^]+)), the script dynamically substitutes these captured values into thedetailMessage(e.g.,$1,$2`). This is how it can extract the exact selector that wasn't found or the specific route that timed out!

5. Data Structuring for CSV: For every failed test, the script consolidates all the extracted information (file paths, titles, categories, priorities, raw error data) into a clean JavaScript object. These objects populate an array called reportData.

6. CSV Conversion and Output: Finally, the papaparse library takes the reportData array and converts it into a well-formatted CSV string, complete with a header row. This string is then written to failed_tests_report.csv, ready for review in any spreadsheet software.

Key Benefits of Using the Script:

Actionable Insights: Move beyond just “fail/pass” to “what failed, how critical, and why specifically.”
Time-Saving: Automate what would be hours of manual log analysis.
Consistent Reporting: Generate uniform reports for team communication and stakeholder updates.
Customizable: Easily extend ERROR_CATEGORIZATION_RULES to suit your project's specific error patterns and reporting needs.

Getting Started with Your Automated Report Generator

Ready to transform your Cypress test analysis?

Prerequisites:

Ensure Node.js (v14+) is installed.
Install required packages: npm install --save-dev fs-extra papaparse
Important: Add "type": "module" to your package.json file to enable ES module support and prevent Node.js warnings.

json { "name": "your-cypress-project", "version": "1.0.0", "type": "module", "devDependencies": { "cypress": "^X.Y.Z", "fs-extra": "^A.B.C", "papaparse": "^D.E.F" } }

2. Prepare Your Report:

Execute your Cypress tests to generate Mochawesome JSON reports.
Merge these individual JSON reports into a single file named mergedReport.json in the same directory as your script. (Tools like mochawesome-merge are commonly used for this.)

3. Run the Script:

Place the generate_failed_tests_report.js file in your project directory (e.g., in the root or a scripts folder).
Open your terminal, navigate to that directory, and run:
Bash

sh node generate_failed_tests_report.js

4. Review the Output:

A failed_tests_report.csv file will be generated in the same directory. Open it with your preferred spreadsheet software (Excel, Google Sheets, etc.) to explore your categorized and prioritized test failures.

Customizing Error Categorization

The true power of this script lies in its flexibility. You can continuously refine the ERROR_CATEGORIZATION_RULES to better suit the specific error patterns of your application and test suite.

To add new categories or details:
Open generate_failed_tests_report.js.
Modify the ERROR_CATEGORIZATION_RULES array.
Add new objects for broad categories or nested objects within details for specific error patterns.
Remember to order your rules from most specific/critical to more general, as the first match wins.
Utilize regex capture groups () and $1, $2 in your detailMessage for dynamic, highly informative output.

By investing in this automated analysis, you’re not just fixing bugs faster; you’re building a smarter, more resilient test automation strategy. Embrace your red builds, understand their story, and accelerate your path to a greener, more stable product.

By Mohamed Said Ibrahim on June 14, 2025.

Exported from Medium on October 2, 2025.

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing cypress-angular-commands

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:45:42 +0000

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing cypress-angular-commands

A game-changing NPM package with 80+ reusable, production-grade Cypress custom commands designed for Angular-based enterprise applications…

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing `cypress-angular-commands`

A game-changing NPM package with 80+ reusable, production-grade Cypress custom commands designed for Angular-based enterprise applications and ERP systems.

✅ Why You Should Read This

Angular apps are beautiful, but they’re also notoriously complex to test.

Whether you’re dealing with:

🧾 dynamic forms with cascading dropdowns
📊 tables with filters, search, and conditional rows
🛑 UI components that render on the fly
🧠 flaky async behavior in enterprise workflows

…then this package was built for you.

🚀 Meet `cypress-angular-commands`

A battle-tested collection of professionally structured, fully typed, and plug-and-play Cypress custom commands for testing Angular/PrimeNG/Material UI frontends like a pro.

📦 Install now:

npm install cypress-angular-commands

🎯 What Makes It Special?

This package isn’t just another utility helper — it’s the result of years of experience automating real-world ERP modules across Sales, Finance, HR, and Inventory apps.

Here’s what you get:

✅ 80+ Cypress custom commands, organized into 14 categories

✅ 📂 Auto-install to your cypress/support folder

✅ 🧠 Professionally named commands that match real-world scenarios

✅ ⚙️ Zero configuration — works with your existing tests

✅ 🚀 TypeScript-ready with stable assertions and custom retries

Supercharge Your Angular E2E Testing with Cypress

📚 Coverage You Can Count On

Here’s just a glimpse of what’s inside:

Coverage You Can Count On

🛠 Install and Set Up in Seconds

📦 Install via NPM

npm install cypress-angular-commands

2. ⚙️ Add to your project’s scripts

"scripts": {   "install:commands": "node ./node_modules/cypress-angular-commands/scripts/install-commands.js" }

3. 🚀 Run the command

npm run install:commands

✅ This will:

Copy all command files to cypress/support/angular-commands/
Append their import to your support/index.ts
Respect your existing setup — no overwrites, no conflicts

🔍 Real Example: Clean, Readable, Robust

// Verify search filters a table  
cy.verifySearchFunctionality('\[data-test="search-input"\]', \[1, 2\]);  

// Extract value from table where another cell matches  
cy.getCellValueWhenCondition(2, 0, 'Approved').then((text) => {  
  expect(text).to.contain('Invoice');  
});  
// Validate placeholder and label text  
cy.verifyLabelText('\[data-test="email-label"\]', 'Email');  
cy.verifyPlaceholder('\[data-test="email-input"\]', 'Enter your email');

🔥 Now you write less test code and test more use cases.

🧪 Built for:

✅ Cypress 13.x+

✅ Angular 12+ (PrimeNG, Material, Bootstrap)

✅ TypeScript or JavaScript Cypress setups

✅ Enterprise apps, ERP systems, B2B UIs

✅ Developers and QA teams looking to move fast and stay stable

💼 Use Cases in the Wild

Large ERP apps with dynamic tables and dropdowns
Complex form validations with toggles, checkboxes, and modals
List views and grids with asynchronous rendering
Workflows that require advanced input and navigation flows
Teams who need confidence, speed, and maintainability

🔐 Safe for Existing Projects

This package does not overwrite anything.

It:

Creates a separate folder support/angular-commands/
Appends safe imports to index.ts only if needed
Respects your existing files and custom commands

✅ It extends — not replaces — your existing Cypress setup.

👨‍💻 About the Author

Mohamed Said

Automation Architect | QA Mentor | Cypress Expert

🔗 LinkedIn

🔗 GitHub

🔗 Medium

📈 You have read about:

Cypress Angular custom commands
Cypress table testing for PrimeNG
Cypress reusable dropdown assertions
Cypress ERP test automation
Cypress UI automation for Angular
Cypress custom utilities for complex apps

❤️ Final Words

If you’re tired of flaky Cypress tests or wasting time writing the same table and form logic again and again — install this package and let it do the heavy lifting for you.

✅ Faster tests

✅ Cleaner specs

✅ More time to focus on what matters

📦 Install now:

npm install cypress-angular-commands  
npm run install:commands

⭐️ Star it, share it, and tell your QA team — it’s time to automate smarter.

By Mohamed Said Ibrahim on June 20, 2025.

Exported from Medium on October 2, 2025.

🔐 Supercharge Your Test Stability with cy.ensurePageIsReady() in Cypress.io

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:43:15 +0000

🔐 Supercharge Your Test Stability with cy.ensurePageIsReady() in Cypress.io

In the fast-paced world of web applications, testing isn’t just about clicking buttons — it’s about ensuring that every element is truly…

🔐 Supercharge Your Test Stability with `cy.ensurePageIsReady()` in Cypress.io

In the fast-paced world of web applications, testing isn’t just about clicking buttons — it’s about ensuring that every element is truly ready before interaction begins. As automation engineers, we’ve all battled with flaky tests, unpredictable UI loaders, and unstable screens that lead to false negatives in our test runs.

If you’re building serious E2E tests with Cypress.io, there’s one custom command you can’t afford to ignore:

✅ *cy.ensurePageIsReady()*

This powerful utility wraps the best of Cypress stability practices into one unified and reliable command, ensuring your test execution waits for:

🔄 All network requests to complete
🎯 All UI components to be rendered
🧘‍♀️ The DOM to stabilize

Let’s dive into why and how this command should become a core part of your test automation toolbox.

🚀 Why `cy.ensurePageIsReady()` Is a Game-Changer

Here’s the real-world problem:

❌ *cy.wait(5000)* is not reliable, not scalable, and definitely not intelligent.

Modern apps built with Angular, React, Vue, or PrimeNG load data asynchronously and often update the DOM multiple times after the page “looks” ready. Your test might click on a button just before it’s really ready — resulting in flaky or failed tests.

This is where cy.ensurePageIsReady() shines.

✅ What It Does (Behind the Scenes)

This custom command intelligently waits for three layers of readiness:

1️⃣ Network Silence Detection

It checks for zero pending XHR requests using Cypress’s access to the browser’s network state.

const pendingRequests = (win as any)._networkState?.pendingRequests || 0;

This avoids proceeding while your app is still fetching data or initializing complex components.

2️⃣ UI Component Stability

It waits for known loading indicators to vanish, including:

.spinner-overlay
.skeleton-loader
Core layout containers like body

cy.get(".spinner-overlay,.skeleton-loader", { timeout: 30000 }).should("not.exist");

This guarantees the UI is ready to interact with.

3️⃣ DOM Mutation Observation

Using MutationObserver, it ensures no further DOM changes are happening due to animations, lazy-loading, or JavaScript framework updates.

const observer = new MutationObserver(() => {  
  lastChange = Date.now();  
});

Only when the DOM is quiet for at least 1000ms, the test proceeds.

🔧 The Custom Command

Here’s the full, production-grade command:

Cypress.Commands.add("ensurePageIsReady", () => {  
  const waitForNetworkIdle = (options = {}) => {  
    const { timeout = 10000, log = true, interval = 500 } = options;  
    if (log) {  
      Cypress.log({  
        name: 'waitForNetworkIdle',  
        message: `Waiting for network idle (timeout: ${timeout}ms)`,  
      });  
    }  
return cy.window({ log: false }).then({ timeout: timeout + 1000 }, (win) => {  
      return new Cypress.Promise<void>((resolve, reject) => {  
        const timeoutId = setTimeout(() => reject(new Error("Network idle timeout")), timeout);  
        const check = () => {  
          const pending = (win as any)._networkState?.pendingRequests || 0;  
          if (pending === 0) {  
            clearTimeout(timeoutId);  
            resolve();  
          } else {  
            setTimeout(check, interval);  
          }  
        };  
        check();  
      });  
    });  
  };  
  const waitForDOMStability = () => {  
    cy.window().then((win) => {  
      return new Cypress.Promise<void>((resolve) => {  
        let lastChange = Date.now();  
        const observer = new MutationObserver(() => lastChange = Date.now());  
        observer.observe(win.document.body, { childList: true, subtree: true, attributes: true });  
        const check = () => {  
          if (Date.now() - lastChange > 1000) {  
            observer.disconnect();  
            resolve();  
          } else {  
            setTimeout(check, 500);  
          }  
        };  
        check();  
      });  
    });  
  };  
  const waitForUIComponents = () => {  
    cy.get("body", { timeout: 60000 }).should("be.visible");  
    cy.get(".spinner-overlay,.skeleton-loader", { timeout: 30000 }).should("not.exist");  
  };  
  cy.log("🔎 Ensuring page is fully stable...");  
  waitForNetworkIdle();  
  waitForUIComponents();  
  waitForDOMStability();  
  cy.log("✅ Page is ready for testing.");  
});

🧪 When to Use It

Use cy.ensurePageIsReady() anywhere you:

Visit a page with dynamic content
Navigate between modules
Login or load dashboards
Click dropdowns or date pickers that trigger async loading
Wait before asserting UI state

📌 Real-World Usage Example

cy.visit('/erp/transactions');  
cy.ensurePageIsReady();  

cy.get('[data-testid="addInvoice"]').click();  
cy.ensurePageIsReady();  
cy.get('input[data-testid="invoiceNo"]').should('be.visible');

No cy.wait(4000), no guessing — just deterministic, clean, stable tests.

🧠 Final Thoughts

“Flaky tests are worse than no tests.”

— Every QA Engineer Ever

By introducing cy.ensurePageIsReady() into your Cypress project, you're building resilient, scalable, and deterministic automation.

This command is not just a utility — it’s a testing philosophy:

“Wait only as long as needed, and only when it matters.”

🙌 Ready to Take Your Cypress Tests to the Next Level?

🔁 Replace cy.wait() with intelligence

💪 Boost your confidence in test stability

🧩 Build smarter test flows that mimic real user behavior

🔥 Share this post with your team and automate like a pro!

📥 Drop a Comment Below

Let me know:

How do you handle flaky tests in your Cypress projects?
What would you add to cy.ensurePageIsReady()?

Let’s build a smarter, more stable test world — one command at a time.

Written by Mohamed Said Ibrahim, Test Automation Engineer & Cypress Evangelist.

👉 Follow me for more Cypress tips, custom command libraries, and test architecture breakdowns.

By Mohamed Said Ibrahim on June 24, 2025.

Exported from Medium on October 2, 2025.

🧪 How to Test Angular Components with Cypress Component Testing (CT)

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:39:09 +0000

🧪 How to Test Angular Components with Cypress Component Testing (CT)

Submit Buttons, Lookup Dropdowns, Paginators, Calendars & More

🧪 How to Test Angular Components with Cypress Component Testing (CT)

Submit Buttons, Lookup Dropdowns, Paginators, Calendars & More

By Mohamed Said | Test Automation Expert | Medium | 2025

Component testing is an essential practice in front-end quality assurance. With the rise of modern frameworks like Angular, it’s become increasingly important to isolate and test UI components such as buttons, dropdowns, calendars, and paginators — without spinning up the entire application.

Cypress.io, a modern testing framework known for end-to-end testing, now supports Component Testing (CT), which empowers Angular developers and testers to test UI components in isolation with lightning speed and real browser rendering.

In this guide, you’ll learn:

✅ What is Cypress Component Testing (CT)

✅ How to set up Cypress CT in an Angular project

✅ How to test Angular components:

— Submit Button

— Lookup Dropdown

— Calendar DatePicker

— Paginator / Pagination Controls

✅ Best practices for Cypress CT with Angular

✅ Bonus: Tips for clean component test architecture

cypress angular

🧩 What is Cypress Component Testing?

Cypress Component Testing allows you to render individual components in real browsers, interact with them, and assert their behavior — just like users do.

Unlike unit tests that test logic in isolation, component tests render UI, simulate real interaction, and are faster and more maintainable than full E2E tests.

✅ Use real DOM

✅ Real browser environment

✅ Visual feedback in Cypress Test Runner

✅ Hot reload during test development

🚀 Setting Up Cypress Component Testing in Angular

Step 1: Install Cypress Component Testing

npm install \--save-dev cypress @cypress/angular

Step 2: Configure Cypress CT

Generate Cypress config files if you haven’t yet:

npx cypress open --component

Then configure your cypress.config.ts:

import { defineConfig } from 'cypress';  
import { startDevServer } from '@cypress/angular/dev-server';  

export default defineConfig({  
  component: {  
    devServer: {  
      framework: 'angular',  
      bundler: 'webpack',  
    },  
    specPattern: '\*\*/\*.cy.ts',  
  },  
});

Step 3: Add Component Test Support File

Create cypress/support/component.ts:

import './commands';  
import 'cypress-real-events/support';

And update cypress/support/e2e.ts to only load for e2e mode.

🧪 Testing Angular Components with Cypress CT

Let’s explore how to test real-life components used in business Angular apps.

✅ 1. Testing a Submit Button

Component: SubmitButtonComponent

<button data-testid\="submit-btn" (click)="onSubmit()"\>Submit</button\>

Test:

describe('SubmitButtonComponent', () => {  
  it('should trigger submit on click', () => {  
    cy.mount(SubmitButtonComponent, {  
      componentProperties: {  
        onSubmit: cy.stub().as('submitStub'),  
      },  
    });  

cy.get('\[data-testid="submit-btn"\]').click();  
    cy.get('@submitStub').should('have.been.calledOnce');  
  });  
});

🔍 2. Testing a Lookup Dropdown

Component: LookupDropdownComponent

<select data-testid\="lookup-dropdown" \[(ngModel)\]="selectedItem"\>  
  <option \*ngFor\="let item of items" \[value\]="item.id"\>{{ item.name }}</option\>  
</select\>

Test:

describe('LookupDropdownComponent', () => {  
  it('should select an item from dropdown', () => {  
    cy.mount(LookupDropdownComponent, {  
      componentProperties: {  
        items: \[  
          { id: 1, name: 'Apple' },  
          { id: 2, name: 'Orange' },  
        \],  
        selectedItem: 1,  
      },  
    });  

cy.get('\[data-testid="lookup-dropdown"\]').select('2');  
    cy.get('\[data-testid="lookup-dropdown"\]').should('have.value', '2');  
  });  
});

📅 3. Testing a Calendar / Date Picker

Component: Angular Material Datepicker or PrimeNG Calendar

Example (Material):

<mat-form-field\>  
  <input matInput \[matDatepicker\]="picker" \[(ngModel)\]="selectedDate" data-testid\="calendar"\>  
  <mat-datepicker #picker\></mat-datepicker\>  
</mat-form-field\>

Test:

describe('CalendarComponent', () => {  
  it('should open calendar and select a date', () => {  
    cy.mount(CalendarComponent);  
cy.get('\[data-testid="calendar"\]').click();  
    cy.get('.mat-calendar-body-cell-content').contains('15').click();  
    cy.get('\[data-testid="calendar"\]').should('contain.value', '15');  
  });  
});

📄 4. Testing a Paginator

Component: PaginatorComponent

<mat-paginator  
  \[length\]="100"  
  \[pageSize\]="10"  
  \[pageSizeOptions\]="\[5, 10, 20\]"  
  (page)="onPageChange($event)"\>  
</mat-paginator>

Test:

describe('PaginatorComponent', () => {  
  it('should emit page change', () => {  
    cy.mount(PaginatorComponent, {  
      componentProperties: {  
        onPageChange: cy.stub().as('pageChange'),  
      },  
    });  
cy.get('button.mat-paginator-navigation-next').click();  
    cy.get('@pageChange').should('have.been.called');  
  });  
});

📌 Best Practices

✅ Use data-testid attributes to select elements reliably

✅ Stub output/event emitters to track actions

✅ Avoid asserting internal logic—focus on behavior

✅ Use Cypress cy.mount() to isolate and test component behavior

✅ Test edge cases: disabled buttons, empty dropdowns, boundary paginations

🧱 Clean Component Test Architecture

Organize your tests like:

src/

├── app/

│ ├── shared/

│ │ ├── submit-button/

│ │ │ ├── submit-button.component.ts

│ │ │ ├── submit-button.component.cy.ts ✅

This keeps component and test code tightly coupled and easy to maintain.

📊 Why Cypress CT is a Game-Changer for Angular Devs

🌐 Real browser environment (vs. jsdom)
⚡ Instant feedback with hot reload
🎥 Visual debugging in the Cypress Test Runner
🧪 Great for micro frontend architecture

Whether you’re testing a form submission, a complex dropdown, or a calendar with custom validations, Cypress CT makes your Angular UI testing scalable, fast, and developer-friendly.

📣 Final Thoughts

Modern Angular apps deserve modern testing strategies. Cypress Component Testing allows you to test reusable UI pieces in real scenarios, speeding up development and preventing regression bugs early.

🔔 Start small: Test your button component today.

🧱 Scale fast: Expand to forms, dialogs, dropdowns, paginators.

💡 Own your UI quality — with Cypress + Angular.

🧠 Bonus: Want More?

💬 Drop a comment or connect with me on LinkedIn

📦 NPM: cypress-enterprise-commands

📹 Coming soon: Full Udemy course on Cypress + Angular testing!

🔖 Tags:

#Angular #Cypress #ComponentTesting #TestAutomation #WebTesting #Frontend #JavaScript #UIUX #QA #EndToEndTesting

Thank you for being a part of the community

Before you go:

Be sure to clap and follow the writer ️👏️️
Follow us: X | LinkedIn | YouTube | Newsletter | Podcast | Twitch
Start your own free AI-powered blog on Differ 🚀
Join our content creators community on Discord 🧑🏻‍💻
For more content, visit plainenglish.io + stackademic.com

By Mohamed Said Ibrahim on June 29, 2025.

Exported from Medium on October 2, 2025.

Angular Dropdown Demystified: Comprehensive Component Testing with Cypress and PrimeNG

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:33:54 +0000

Angular Dropdown Demystified: Comprehensive Component Testing with Cypress and PrimeNG

Interactive dropdowns are a cornerstone of modern web applications, offering users intuitive ways to select options. When working with UI…

Angular Dropdown Demystified: Comprehensive Component Testing with Cypress and PrimeNG

Interactive dropdowns are a cornerstone of modern web applications, offering users intuitive ways to select options. When working with UI libraries like PrimeNG, these components become even more powerful but also introduce a unique set of testing challenges. How do you ensure a p-dropdown not only renders correctly but also handles user interactions, data changes, and edge cases flawlessly?

This article dives deep into building a robust, professional component test suite for an Angular dropdown, specifically using PrimeNG’s p-dropdown and Cypress. We’ll explore best practices for data stubbing, covering positive, negative, and edge test cases, all while maintaining excellent file separation for a clean and maintainable codebase.

Angular Dropdown Demystified: Comprehensive Component Testing with Cypress and PrimeNG

Why Component Testing is Your Secret Weapon

In the fast-paced world of frontend development, high-quality testing is non-negotiable. Component testing, in particular, offers significant advantages:

● Pinpoint Accuracy: Isolate and test individual components in a controlled environment, making it easier to identify the source of bugs.

● Rapid Feedback Loop: Component tests execute quickly, providing immediate feedback during development cycles.

● Future-Proofing: Confidently refactor or update your component’s internal logic without fear of breaking existing functionality.

● Executable Documentation: Tests serve as clear, living examples of how your component should behave and be interacted with.

● Dependency Management: Stubbing external data and services in component tests allows you to focus purely on the component’s UI and logic.

Our Subject: The PrimeNG Vendor Dropdown

Let’s imagine we’re building a form where users need to select a vendor. We’ll leverage PrimeNG’s p-dropdown for this, encapsulating it within our own app-vendor-dropdown component for better reusability and testability.

The core HTML for our dropdown will resemble:

<p-dropdown data-testid\="vendorId" …>…</p-dropdown\>

The Art of Separation: Component vs. Test File

A clean project structure is vital for maintainability, especially in larger applications. We’ll strictly separate our Angular component definition from its testing logic.

Part 1: The Reusable Angular Dropdown Component (src/app/vendor-dropdown/vendor-dropdown.component.ts)

We’ll wrap the p-dropdown in a dedicated component, exposing its core functionalities via @Input() and @Output(). This makes it highly configurable and testable.

// src/app/vendor-dropdown/vendor-dropdown.component.ts  
import { Component, EventEmitter, Input, Output, OnInit } from '@angular/core';  
import { CommonModule } from '@angular/common';  
import { FormsModule } from '@angular/forms';  
import { DropdownModule } from 'primeng/dropdown';  
import { ChevronDownIcon } from 'primeng/icons/chevrondown'; // Important for PrimeNG's internal icon  
export interface Vendor { // Define a clear data structure  
id: number;  
name: string;  
}  
@Component({  
selector: 'app-vendor-dropdown',  
template: `  
<div class="vendor-dropdown-container">  
<p-dropdown  
[options]="vendors"  
[(ngModel)]="selectedVendor"  
optionLabel="name"  
optionValue="id"  
[placeholder]="placeholder"  
[disabled]="isDisabled"  
[showClear]="showClear"  
[filter]="filterEnabled"  
data-testid="vendorId"  
(onChange)="onVendorChange($event)"  
(onFocus)="onFocusEvent.emit()"  
(onBlur)="onBlurEvent.emit()"  
>  
<ng-template pTemplate="selectedItem">…</ng-template>  
<ng-template let-vendor pTemplate="item">…</ng-template>  
<ng-template pTemplate="dropdownicon">…</ng-template>  
</p-dropdown>  
</div>  
`,  
standalone: true, // Angular 14+ feature for simplified module setup  
imports: [  
CommonModule,  
FormsModule, // Required for ngModel two-way binding  
DropdownModule, // PrimeNG Dropdown Component  
ChevronDownIcon // PrimeNG's specific icon component  
],  
})  

export class VendorDropdownComponent implements OnInit {  
@Input() vendors: Vendor[] = []; // Data source for dropdown items  
@Input() initialVendorId: number | null = null; // Pre-select an item by ID  
@Input() placeholder: string = 'Select a Vendor';  
@Input() isDisabled: boolean = false;  
@Input() showClear: boolean = false;  
@Input() filterEnabled: boolean = false;  
@Output() vendorSelected = new EventEmitter<Vendor | null>(); // Emits the selected Vendor object  
@Output() onFocusEvent = new EventEmitter<void>();  
@Output() onBlurEvent = new EventEmitter<void>();  
_selectedVendor: number | null = null; // Internal ngModel for the dropdown  

get selectedVendor(): number | null { return this._selectedVendor; }  

@Input() set selectedVendor(value: number | null) {  
if (this._selectedVendor !== value) {  
this._selectedVendor = value;  
}  
}  

ngOnInit(): void {  
if (this.initialVendorId !== null) {  
this.selectedVendor = this.initialVendorId;  
}  
}  

onVendorChange(event: any): void {  
const selectedVendorObject = this.vendors.find(v => v.id === event.value);  
this.vendorSelected.emit(selectedVendorObject || null);  
}  

// Helper for displaying selected vendor name in template  
getSelectedVendorName(id: number | null): string {  
const vendor = this.vendors.find(v => v.id === id);  
return vendor ? vendor.name : '';  
}  

}

Component Highlights:

● @Input() & @Output(): The bedrock of component communication, making our component flexible.

● data-testid=”vendorId”: The golden rule for robust Cypress selectors.

● standalone: true: Modern Angular component declaration, reducing boilerplate.

● FormsModule & DropdownModule: Essential PrimeNG and Angular modules for functionality.

● Vendor Interface: Strong typing for predictable data.

● getSelectedVendorName: A small helper for template logic.

Part 2: The Comprehensive Cypress Component Test Suite (cypress/component/vendor-dropdown.cy.ts)

This file will be the testing powerhouse, residing in a dedicated cypress/component directory.

// cypress/component/vendor-dropdown.cy.ts  
import { VendorDropdownComponent, Vendor } from '../../src/app/vendor-dropdown/vendor-dropdown.component';  
// - - Professional Data Stubbing - -  
// Define representative test data  
const STUB\_VENDORS: Vendor\[\] = \[  
{ id: 1, name: 'Alpha Solutions' },  
{ id: 2, name: 'Beta Innovations' },  
{ id: 3, name: 'Gamma Enterprises' },  
{ id: 4, name: 'Delta Corp' },  
{ id: 5, name: 'Epsilon Tech' },  
\];  

const EMPTY\_VENDORS: Vendor\[\] = \[\]; // For edge case: empty data  
const SINGLE\_VENDOR: Vendor\[\] = \[{ id: 10, name: 'One-Stop Shop' }\]; // For edge case: single item  


describe('VendorDropdownComponent (PrimeNG Integration Test)', () => {  
beforeEach(() => {  
// Ensure sufficient viewport size for PrimeNG overlay  
cy.viewport(1000, 600);  
});  

// - - Positive Test Cases: Happy Paths - -  
it('should render with default placeholder and be initially empty', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Select a Vendor');  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('have.class', 'p-placeholder');  
});  

it('should open the dropdown and display all options upon click', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS } });  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-panel').should('be.visible');  
cy.get('.p-dropdown-item').should('have.length', STUB\_VENDORS.length);  
STUB\_VENDORS.forEach(vendor => {  
cy.get('.p-dropdown-item').should('contain.text', vendor.name);  
});  
});  

it('should select an option and update the displayed value, emitting the correct object', () => {  
const onVendorSelectedSpy = cy.spy().as('vendorSelectedSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, vendorSelected: onVendorSelectedSpy } });  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-item').eq(1).click(); // Select 'Beta Innovations'  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Beta Innovations');  
cy.get('@vendorSelectedSpy').should('have.been.calledWith', STUB\_VENDORS\[1\]);  
});  

it('should pre-select a vendor based on initialVendorId input', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, initialVendorId: STUB\_VENDORS\[2\].id } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Gamma Enterprises');  
});  

it('should enable filtering and correctly narrow down options', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, filterEnabled: true } });  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-filter').type('delta'); // Case-insensitive search  
cy.get('.p-dropdown-item').should('have.length', 1);  
cy.get('.p-dropdown-item').should('contain.text', 'Delta Corp');  
});  

it('should display a clear button and clear the selection, emitting null', () => {  
const onVendorSelectedSpy = cy.spy().as('vendorSelectedSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, initialVendorId: STUB\_VENDORS\[0\].id, showClear: true, vendorSelected: onVendorSelectedSpy } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-clear-icon').should('be.visible').click();  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Select a Vendor');  
cy.get('@vendorSelectedSpy').should('have.been.calledWith', null);  
});  


// - - Negative Test Cases: Error Handling and Invalid States - -  
it('should disable the dropdown when isDisabled is true and prevent interaction', () => {  
const onVendorSelectedSpy = cy.spy().as('vendorSelectedSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, isDisabled: true, vendorSelected: onVendorSelectedSpy } });  
cy.get('\[data-testid="vendorId"\]').should('have.class', 'p-disabled');  
cy.get('\[data-testid="vendorId"\]').click({ force: true }); // Attempt a forced click  
cy.get('.p-dropdown-panel').should('not.exist'); // Panel should not open  
cy.get('@vendorSelectedSpy').should('not.have.been.called'); // No selection should occur  
});  

it('should not select a value if initialVendorId does not match any available vendor', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, initialVendorId: 9999 } }); // Non-existent ID  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Select a Vendor');  
});  

it('should show "No results found" message when filter yields no matches', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, filterEnabled: true } });  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-filter').type('nonexistent');  
cy.get('.p-dropdown-empty-message').should('be.visible').and('contain.text', 'No results found');  
cy.get('.p-dropdown-item').should('not.exist');  
});  


// - - Edge Test Cases: Boundary Conditions - -  
it('should correctly display placeholder and no options when vendors array is empty', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: EMPTY\_VENDORS, placeholder: 'No data available' } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'No data available');  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-panel').should('be.visible'); // Panel still opens  
cy.get('.p-dropdown-item').should('not.exist');  
cy.get('.p-dropdown-empty-message').should('be.visible');  
});  

it('should handle single option gracefully and allow selection', () => {  
const onVendorSelectedSpy = cy.spy().as('vendorSelectedSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: SINGLE\_VENDOR, vendorSelected: onVendorSelectedSpy } });  
cy.get('\[data-testid="vendorId"\]').click();  
cy.get('.p-dropdown-item').should('have.length', 1);  
cy.get('.p-dropdown-item').first().click();  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'One-Stop Shop');  
cy.get('@vendorSelectedSpy').should('have.been.calledWith', SINGLE\_VENDOR\[0\]);  
});  

it('should reset filter text and results when dropdown is closed and re-opened', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, filterEnabled: true } });  
cy.get('\[data-testid="vendorId"\]').click(); // Open  
cy.get('.p-dropdown-filter').type('xyz'); // Filter, no results  
cy.get('body').click(0, 0); // Click outside to close  
cy.get('\[data-testid="vendorId"\]').click(); // Re-open  
cy.get('.p-dropdown-filter').should('have.value', ''); // Filter input should be cleared  
cy.get('.p-dropdown-item').should('have.length', STUB\_VENDORS.length); // All options visible again  
});  


// - - Accessibility Test Cases: Ensuring Usability for All - -  
it('should have correct ARIA attributes for a combobox role', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS } });  
cy.get('\[data-testid="vendorId"\] \[role="combobox"\]')  
.should('have.attr', 'aria-haspopup', 'listbox')  
.and('have.attr', 'aria-expanded', 'false') // Initially closed  
.and('have.attr', 'aria-label', 'Select a Vendor'); // Default placeholder becomes label  
cy.get('\[data-testid="vendorId"\]').click(); // Open  
cy.get('\[data-testid="vendorId"\] \[role="combobox"\]').should('have.attr', 'aria-expanded', 'true');  
cy.get('.p-dropdown-panel\[role="listbox"\]').should('be.visible');  
});  

it('should support keyboard navigation (ArrowDown to open, Enter to select)', () => {  
const onVendorSelectedSpy = cy.spy().as('vendorSelectedSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, vendorSelected: onVendorSelectedSpy } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').focus().type('{downarrow}'); // Focus and open  
cy.get('.p-dropdown-panel').should('be.visible');  
cy.get('.p-dropdown-item').eq(0).should('have.class', 'p-highlight'); // First item highlighted  
cy.focused().type('{downarrow}'); // Move to Beta  
cy.focused().type('{downarrow}'); // Move to Gamma  
cy.focused().type('{enter}'); // Select Gamma  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').should('contain.text', 'Gamma Enterprises');  
cy.get('@vendorSelectedSpy').should('have.been.calledWith', STUB\_VENDORS\[2\]);  
});  

it('should close the dropdown when Escape key is pressed', () => {  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS } });  
cy.get('\[data-testid="vendorId"\]').click(); // Open  
cy.get('.p-dropdown-panel').should('be.visible');  
cy.get('body').type('{esc}'); // Simulate Escape key press  
cy.get('.p-dropdown-panel').should('not.exist');  
});  

it('should emit onFocus event', () => {  
const onFocusSpy = cy.spy().as('onFocusSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, onFocusEvent: onFocusSpy } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').focus();  
cy.get('@onFocusSpy').should('have.been.calledOnce');  
});  

it('should emit onBlur event', () => {  
const onBlurSpy = cy.spy().as('onBlurSpy');  
cy.mount(VendorDropdownComponent, { componentProperties: { vendors: STUB\_VENDORS, onBlurEvent: onBlurSpy } });  
cy.get('\[data-testid="vendorId"\] .p-dropdown-label').focus();  
cy.get('body').click(0, 0); // Click outside to trigger blur  
cy.get('@onBlurSpy').should('have.been.calledOnce');  
});  
});

Test Suite Highlights:

● STUB_VENDORS, EMPTY_VENDORS, SINGLE_VENDOR: Demonstrates professional data stubbing. This isolated, representative data ensures tests are fast, predictable, and not reliant on external APIs or complex data generation.

● Comprehensive Coverage:

○ Positive: Basic rendering, opening/closing, selection, initial value, filtering, clear button.

○ Negative: Disabled state behavior, invalid initialVendorId, no filter matches.

○ Edge Cases: Empty options list, single option list, filter reset on close.

● Accessibility (aria-* attributes, keyboard navigation): Crucial for inclusive UIs. PrimeNG handles much of this, but it’s vital to verify.

● cy.mount(Component, { componentProperties: { … } }): The core of Cypress component testing, allowing us to pass inputs and spy on outputs.

● cy.spy().as(): For robust verification of EventEmitter outputs.

● Reliable Selectors: Primarily data-testid=”vendorId”, falling back to PrimeNG’s stable internal classes (.p-dropdown-item, .p-dropdown-label, .p-dropdown-panel, etc.) when necessary. Avoid brittle CSS classes generated by PrimeNG if more stable options exist.

● beforeEach for Setup: Ensures a clean state for each test.

● cy.viewport(): Important for components with overlays, ensuring the dropdown panel appears correctly in the test runner.

Conclusion

Testing complex components like PrimeNG’s p-dropdown doesn’t have to be daunting. By following a structured approach that emphasizes:

1. Component Encapsulation: Wrapping external UI components in your own Angular component.

2. Clear Input/Output Contracts: Defining precise @Input() and @Output() properties.

3. Professional Data Stubbing: Using isolated, representative data for testing.

4. Comprehensive Test Scenarios: Covering positive, negative, and edge cases.

5. Robust Selectors: Leveraging data-testid and stable library classes.

6. File Separation: Organizing your component code and test suite into distinct files.

You can build a highly reliable and maintainable frontend application. This detailed guide provides a strong foundation for ensuring your Angular components, even those integrated with powerful libraries, perform flawlessly, enhancing both developer confidence and end-user experience.

By Mohamed Said Ibrahim on July 1, 2025.

Exported from Medium on October 2, 2025.

Supercharging Angular Component Tests with Cypress: The Power of cy.stub() within cy.mount()

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:30:29 +0000

Supercharging Angular Component Tests with Cypress: The Power of cy.stub() within cy.mount()

Testing user interfaces effectively is crucial for building robust web applications. In the Angular ecosystem, Cypress has emerged as a…

Supercharging Angular Component Tests with Cypress: The Power of cy.stub() within cy.mount()

Testing user interfaces effectively is crucial for building robust web applications. In the Angular ecosystem, Cypress has emerged as a powerhouse for both end-to-end and component testing. While cy.mount() provides a seamless way to render your Angular components in isolation, the real magic happens when you combine it with cy.stub(). This dynamic duo allows you to precisely control component dependencies, enabling focused, fast, and reliable tests.

This article dives deep into the art of using cy.stub() inside cy.mount() in Cypress for Angular component testing, exploring its benefits, practical examples, and best practices to help you write cleaner, more effective tests.

Why Component Testing Matters (and How Stubbing Enhances It)

Component testing focuses on verifying individual UI components in isolation, ensuring they function correctly independent of their surrounding application or external services. This approach offers several advantages:

● Faster Feedback: Tests run quickly as they don’t require the entire application stack.

● Precise Isolation: Pinpoint bugs within a specific component without interference from other parts of the system.

● Easier Debugging: When a test fails, you know exactly which component is at fault.

● Improved Maintainability: Isolated tests are less brittle and easier to update as your application evolves.

However, components often have dependencies — services that fetch data, other child components, or even browser APIs. If you test a component with its real dependencies, your test becomes an integration test rather than a true component test. This is where cy.stub() comes to the rescue.

Stubbing allows you to replace a real dependency with a controlled, test-specific version. You can dictate what the stubbed dependency returns, how it behaves, and even track if it was called. This empowers you to:

● Control Data: Simulate various data states (empty, error, loading, different data sets) without needing a real backend.

● Prevent Side Effects: Stop actual HTTP requests, local storage writes, or navigation events during tests.

● Test Edge Cases: Easily simulate failure scenarios, network errors, or permissions issues.

● Verify Interactions: Confirm that your component correctly calls its dependencies with the right arguments.

The Synergy: cy.stub() and cy.mount() in Action

Cypress’s cy.mount() for Angular works by leveraging Angular’s TestBed internally, providing a familiar and powerful way to configure your component’s testing environment. The key to integrating cy.stub() lies in the providers array within the cy.mount() configuration object.

Here’s a step-by-step breakdown with a practical example:

Let’s imagine a ProductService that fetches product details and a ProductDetailComponent that displays them.

1. The ProductService (e.g., product.service.ts):

import { Injectable } from '@angular/core';  
import { Observable, of, throwError } from 'rxjs';  
import { delay } from 'rxjs/operators';  

export interface Product {  
id: number;  
name: string;  
price: number;  
description: string;  
}  

@Injectable({  
providedIn: 'root',  
})  

export class ProductService {  
getProduct(id: number): Observable<Product\> {  
// Simulate API call  
if (id === 1) {  
return of({  
id: 1,  
name: 'Cypress Mug',  
price: 19.99,  
description: 'A stylish mug for your coffee.',  
}).pipe(delay(100)); // Simulate a small delay  
} else if (id === 2) {  
return of({  
id: 2,  
name: 'Angular Hoodie',  
price: 49.99,  
description: 'Stay warm while coding.',  
}).pipe(delay(100));  
}  
return throwError(() => new Error('Product not found'));  
}  
}

2. The ProductDetailComponent (e.g., product-detail.component.ts):

import { Component, OnInit, Input } from '@angular/core';  
import { Product, ProductService } from './product.service';  
import { CommonModule } from '@angular/common'; // Needed for \*ngIf  

@Component({  
selector: 'app-product-detail',  
template: \`  
<div \*ngIf="product">  
<h2>{{ product.name }}</h2>  
<p>Price: \\${{ product.price | number:'1.2–2' }}</p>  
<p>{{ product.description }}</p>  
</div>  
<div \*ngIf="errorMessage">  
<p class="error-message">Error: {{ errorMessage }}</p>  
</div>  
<div \*ngIf="!product && !errorMessage">  
<p>Loading product details…</p>  
</div>  
\`,  
standalone: true, // Example with standalone component  
imports: \[CommonModule\],  
})  

export class ProductDetailComponent implements OnInit {  
@Input() productId: number;  
product: Product | null = null;  
errorMessage: string | null = null;  
constructor(private productService: ProductService) {}  
ngOnInit() {  
if (this.productId) {  
this.productService.getProduct(this.productId).subscribe({  
next: (p) => (this.product = p),  
error: (err) => (this.errorMessage = err.message || 'Unknown error'),  
});  
}  
}  
}

3. The Cypress Component Test (e.g., product-detail.component.cy.ts):

import { mount } from 'cypress/angular';  
import { ProductDetailComponent } from './product-detail.component';  
import { ProductService, Product } from './product.service'; // Import for type safety  

describe('ProductDetailComponent', () => {  

it('should display product details when data is successfully fetched', () => {  

const mockProduct: Product = {  
id: 101,  
name: 'Stubbed Widget',  
price: 29.95,  
description: 'A fantastic widget from our stubbed service.',  
};  
// Create a stub for the ProductService's getProduct method  
const getProductStub = cy.stub().returns(mockProduct).as('getProductStub');  
mount(ProductDetailComponent, {  
componentProperties: {  
productId: 101,  
},  
providers: \[  
{  
provide: ProductService,  
useValue: {  
getProduct: getProductStub, // Provide our stubbed method  
},  
},  
\],  
});  
// Assert that the component displays the stubbed data  
cy.contains('h2', 'Stubbed Widget').should('be.visible');  
cy.contains('Price: $29.95').should('be.visible');  
cy.contains('A fantastic widget from our stubbed service.').should('be.visible');  
// Assert that the stubbed method was called with the correct ID  
cy.get('@getProductStub').should('have.been.calledWith', 101);  
});  


it('should display a loading message initially and then product data', () => {  
const mockProduct: Product = {  
id: 102,  
name: 'Async Gadget',  
price: 99.00,  
description: 'An advanced gadget with delayed delivery.',  
};  
// Create a stub that returns an observable resolving after a delay  
let resolveProduct: (value: Product) => void;  
const getProductStub = cy.stub().returns(  
new Cypress.Promise<Product>((resolve) => {  
resolveProduct = resolve;  
}).then((val) => {  
return val; // Ensure the promise resolves  
})  
).as('getProductStub');  
mount(ProductDetailComponent, {  
componentProperties: {  
productId: 102,  
},  
providers: \[  
{  
provide: ProductService,  
useValue: {  
getProduct: getProductStub,  
},  
},  
\],  
});  
// Verify loading state  
cy.contains('p', 'Loading product details…').should('be.visible');  
cy.get('h2').should('not.exist'); // Product not yet displayed  
// Resolve the promise to simulate data arrival  
resolveProduct!(mockProduct);  
// Wait for the component to re-render with data  
cy.contains('h2', 'Async Gadget').should('be.visible');  
cy.contains('Price: $99.00').should('be.visible');  
});  


it('should display an error message if the service call fails', () => {  
const errorMessage = 'Failed to load product: Network Error';  
// Create a stub that returns an observable that immediately throws an error  
const getProductStub = cy.stub().returns(  
Cypress.Rx.throwError(() => new Error(errorMessage))  
).as('getProductStub');  
mount(ProductDetailComponent, {  
componentProperties: {  
productId: 999, // A non-existent product  
},  
providers: \[  
{  
provide: ProductService,  
useValue: {  
getProduct: getProductStub,  
},  
},  
\],  
});  
// Assert that the error message is displayed  
cy.contains('.error-message', \`Error: ${errorMessage}\`).should('be.visible');  
cy.get('@getProductStub').should('have.been.calledWith', 999);  
});  
});

Deconstructing the Power: Key Concepts and Best Practices

providers Array: This is the cornerstone of dependency injection in Angular. When using cy.mount(), the providers array in the second argument acts exactly like the providers array in an Angular NgModule or TestBed.configureTestingModule(). You declare how dependencies should be resolved for the mounted component.

providers: \[  
{ provide: ProductService, useValue: userServiceStub }, // Our stub!  
\],

○ provide: ProductService: This tells Angular’s DI system that whenever ProductService is requested, it should use the value provided.

○ useValue: userServiceStub: Instead of creating a new instance of ProductService, Angular will use userServiceStub as the ProductService instance for this component’s scope.

2. cy.stub() Methods for Controlling Behavior:

○ cy.stub().returns(value): The most common use case. The stubbed function will immediately return the value. Ideal for synchronous operations or observables that complete instantly.

○ cy.stub().resolves(value): For functions that return Promises, this makes the promise resolve with the given value.

○ cy.stub().rejects(error): For functions returning Promises, this makes the promise reject with the specified error.

○ cy.stub().throws(error): Makes the stubbed function throw a synchronous error.

○ cy.stub().callsFake((…args) => { … }): Provides maximum flexibility. You can define a custom function that the stub will execute, allowing for complex logic, multiple return values based on arguments, or even calling a real implementation conditionally.

Asserting on Stubs: After you’ve interacted with your component, it’s vital to ensure that your component interacted correctly with its dependencies. cy.stub() (which is built on Sinon.js) makes this easy:

cy.get('@getProductStub').should('have.been.calledWith', 101);  
cy.get('@getProductStub').should('have.been.calledOnce');  
// More assertions: have.been.calledThrice, have.not.been.called, etc.

○ .as(‘aliasName’): Alias your stub to easily refer to it later using cy.get(‘@aliasName’). This improves readability and maintainability.

4. Handling Asynchronous Operations: When your component deals with Observables (common in Angular with HttpClient), you’ll need to ensure your stubs mimic that asynchronous behavior.

○ Immediate of(): cy.stub().returns(of(mockData)) is perfect for simulating an immediate successful response.

○ Delayed of() and delay(): For testing loading states or race conditions, you can use of(mockData).pipe(delay(someMs)).

○ Manual Resolution with Cypress.Promise: As shown in the Async Gadget example, you can create a Cypress.Promise and resolve it later in your test to precisely control when data arrives, allowing you to test loading indicators.

○ Error Handling: cy.stub().returns(throwError(() => new Error(‘…’))) is essential for testing how your component handles API failures.

When to Stub vs. When to Mock HTTP (cy.intercept())

It’s important to differentiate cy.stub() from cy.intercept().

● cy.stub(): Best for isolating unit-level interactions with services that are injected directly into your component. You’re controlling the method call itself.

● cy.intercept(): Best for mocking HTTP requests at the network level. This is useful when you want to test the entire data flow from your component, through an actual HttpClient service, but without hitting a real backend. cy.intercept() operates at a lower level in the network stack.

For pure component testing, where you want to focus solely on the component’s logic and rendering, cy.stub() is often the preferred choice for its directness and control over injected dependencies.

Conclusion: Elevate Your Angular Component Tests

Integrating cy.stub() within cy.mount() is an indispensable technique for any Angular developer writing Cypress component tests. It empowers you to create highly isolated, predictable, and robust tests that precisely verify your components’ behavior across a multitude of scenarios. By mastering this powerful combination, you’ll gain confidence in your UI, accelerate your development cycles, and ultimately build more reliable Angular applications. Start leveraging this pattern today and witness your testing workflow transform!

By Mohamed Said Ibrahim on July 1, 2025.

Exported from Medium on October 2, 2025.

🚀 How I Built a Robust Cypress.io

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:27:30 +0000

🚀 How I Built a Robust Cypress.io

“Behind every successful automation project, there’s a chaotic first commit.”

🚀 How I Built a Robust Cypress.io Automation Project from Scratch — A Real-World Engineer’s Journey to Excellence

“Behind every successful automation project, there’s a chaotic first commit.”

📍 Introduction

I remember it like it was yesterday. Our mobile-first web application was growing rapidly, and manual testing became a bottleneck. Regression bugs haunted us in every release, and the team was crying out for help. I knew it was time to act.

I decided to build a robust, scalable, and professional Cypress.io automation testing project — something maintainable, extendable, and powerful enough to cover everything from login flows to end-to-end business scenarios. What started as a simple plan turned into a real-world masterclass in Cypress, custom commands, POM, and solving unexpected errors.

This article is your map to follow that journey and build your own Cypress automation project like a pro.

Cypress

🧱 Step 1: Initialize the Project with NPM

First things first, I opened the terminal and ran:

mkdir cypress-floward-e2e  
cd cypress-floward-e2e  
npm init -y

This created the backbone of my project — the package.json file.

🧪 Step 2: Install Cypress

Since Cypress is web-focused and we had some hybrid mobile flows in WebView, I started with the essential web testing stack:
npm install cypress --save-dev

📦 Step 3: Install Required Dependencies

Next, I installed helpful plugins to supercharge my Cypress tests:

npm install \--save-dev cypress-file-upload npm install \--save-dev cypress-axe npm install \--save-dev cypress-xpath

👉 These plugins enabled me to:

Handle file uploads easily.
Test accessibility.
Use powerful XPath selectors when needed.

🗂 Step 4: Create a Clean Project Structure (POM)

To avoid the “spaghetti test code” syndrome, I structured my folders following the Page Object Model (POM):

cypress/

├── fixtures/ # Test data (JSON)

├── integration/ # Test specs

│ └── login/ # login.e2e.cy.js

├── support/

│ ├── commands.js # Custom Cypress commands

│ ├── index.js

│ └── pages/ # POM Files

│ └── LoginPage.js

├── plugins/

This structure made my tests readable, reusable, and scalable.

📄 Step 5: Customize Cypress Configuration

In cypress.config.js:

const { defineConfig } = require('cypress');  

module.exports = defineConfig({  
  e2e: {  
    baseUrl: 'https://floward.com/en-eg/cairo',  
    supportFile: 'cypress/support/index.js',  
    specPattern: 'cypress/integration/\*\*/\*.cy.{js,jsx,ts,tsx}',  
    setupNodeEvents(on, config) {  
      // Add plugins here  
    },  
  },  
  viewportWidth: 1440,  
  viewportHeight: 900,  
});

I also added environment-specific values using .env or cypress.env.json.

🧩 Step 6: Build Custom Commands

Inside cypress/support/commands.js:

Cypress.Commands.add('login', (email, password) => {  
  cy.visit('/login');  
  cy.get('\[data-cy=email\]').type(email);  
  cy.get('\[data-cy=password\]').type(password);  
  cy.get('\[data-cy=submit\]').click();  
});

Now in any test, I can just call:

cy.login('admin@floward.com', 'securePassword!');

💻 Step 7: Write Your First Real Test

login.e2e.cy.js:

import LoginPage from '../../support/pages/LoginPage';  

describe('Login Suite', () => {  
  it('logs in with valid credentials', () => {  
    LoginPage.visit();  
    LoginPage.fillEmail('admin@floward.com');  
    LoginPage.fillPassword('securePassword');  
    LoginPage.submit();  
    cy.contains('Welcome back').should('be.visible');  
  });  
});

LoginPage.js:

class LoginPage {  
  visit() {  
    cy.visit('/login');  
  }  

fillEmail(email) {  
    cy.get('\[data-cy=email\]').type(email);  
  }  
  fillPassword(password) {  
    cy.get('\[data-cy=password\]').type(password);  
  }  
  submit() {  
    cy.get('\[data-cy=submit\]').click();  
  }  
}  
export default new LoginPage();

🧨 Step 8: Conquering Real-World Errors (with Solutions)

❌ Cypress installation fails (Node version mismatch)

Fix:

Update Node.js to the LTS version (18.x or 20.x) and clear the npm cache:

npm cache clean --force

❌ App crashes on WebView or iframe

Fix:

Use the right context-switching commands or access the iframe body:

cy.get('iframe').its('0.contentDocument.body').should('not.be.empty');

❌ Element not found or detached

Fix:

Use should('be.visible') or wait() smartly and avoid hardcoded delays:

cy.get('\[data-cy=submit\]').should('be.visible').click();

📌 Step 9: Bonus Power Moves for Real Teams

🧪 Use data-cy attributes in HTML for reliable element selection.
📸 Add screenshot/video reporting with video: true and screenshotOnRunFailure: true.
🔁 Enable retries:

"retries": {  
  "runMode": 2,  
  "openMode": 0  
}

🔄 Integrate with GitHub Actions or Jenkins CI.

🙌 Final Thoughts

Setting up Cypress wasn’t just about writing tests — it was about creating a test framework that could grow with the app. By using POM, smart selectors, and command abstraction, I reduced code duplication and improved reliability.

👉 This journey transformed our team from firefighting bugs to confidently shipping features.

📈 You are enaged with

Cypress testing tutorial
Cypress automation setup
Cypress POM structure
Cypress custom commands
Cypress installation errors
Cypress vs Appium
Build Cypress project from scratch

📚 Bonus: Want a GitHub Starter Repo or Video Series?

Let me know — I’ll send you the ready-made boilerplate to launch your Cypress automation today.

By Mohamed Said Ibrahim on July 5, 2025.

Exported from Medium on October 2, 2025.

Mastering Angular Component Testing: A Deep Dive with a “Back” Button and Cypress

mohamed Said Ibrahim — Wed, 15 Oct 2025 20:11:25 +0000

Mastering Angular Component Testing: A Deep Dive with a “Back” Button and Cypress

In the world of modern web development, creating robust and reliable user interfaces is paramount. Angular, with its powerful…

Mastering Angular Component Testing: A Deep Dive with a “Back” Button and Cypress

In the world of modern web development, creating robust and reliable user interfaces is paramount. Angular, with its powerful component-based architecture, empowers developers to build complex applications.1 But how do we ensure these individual building blocks, our components, work flawlessly in isolation and as part of the larger system? The answer lies in effective component testing.

This article dives into the art of professional Angular component testing using Cypress, focusing on a common UI element: a simple “Back” button. We’ll explore the best practices of separating your component code from its test suite, leading to cleaner, more maintainable, and highly effective tests.

Why Component Testing Matters

Before we dive into the “how,” let’s briefly touch upon the “why.” Component testing offers several significant advantages:

● Isolation and Focus: Test individual components in isolation, free from the complexities of the entire application.2 This allows you to pinpoint issues quickly.

● Faster Feedback: Component tests run much faster than end-to-end (E2E) tests, providing rapid feedback during development.3

● Improved Maintainability: Well-tested components are easier to refactor and modify with confidence, reducing the risk of introducing regressions.4

● Clearer API Boundaries: Writing tests forces you to think about your component’s inputs (@Input()) and outputs (@Output()), leading to better-designed APIs.

● Living Documentation: Tests serve as executable documentation, illustrating how a component is intended to be used.5

Our Star: The “Back” Button Component

For this demonstration, let’s consider a ubiquitous UI element: a “Back” button. While seemingly simple, it offers a great opportunity to illustrate key testing concepts.

Here’s the HTML structure we’ll be working with:

Back

(Note: We’ll refine the type and title attributes for better semantic correctness in our component.)

Professional Separation: Component and Test Files

A cornerstone of professional development is a well-organized codebase. We will meticulously separate our Angular component definition from its Cypress test suite. This approach promotes modularity, readability, and discoverability.

Step 1: The Angular Back Button Component (src/app/back-button/back-button.component.ts)

First, let’s create a dedicated Angular component file. We’ll make it a standalone component (Angular 14+ feature) for simpler testing setup, and use @Input() and @Output() decorators to make it reusable and configurable.

// src/app/back-button/back-button.component.ts  
import { Component, EventEmitter, Input, Output } from '@angular/core';  
import { CommonModule } from '@angular/common'; // Needed for standalone components  
@Component({  
selector: 'app-back-button', // Unique HTML selector for our button  
template: \`  
<button  
type="button" // Semantically correct button type  
\[title\]="buttonTitle"  
data-testid="cancel" // Excellent for robust Cypress selectors  
class\="btn cancel body\_b16"  
\[style.width\]="buttonWidth"  
(click)="onBack()"  
\[disabled\]="isDisabled"  
\>  
{{ buttonText }}  
</button>  
\`,  
styles: \[\`  
.btn { padding: 10px 15px; border: none; cursor: pointer; font-weight: bold; }  
.cancel { background-color: #f0f0f0; color: #333; }  
.body\_b16 { font-size: 16px; }  
\`\],  
standalone: true, // Enables standalone component usage  
imports: \[CommonModule\], // Import necessary Angular modules  
})  
export class BackButtonComponent {  
@Input() buttonText: string = 'Back';  
@Input() buttonTitle: string = 'Go back to the previous page'; // Descriptive title  
@Input() buttonWidth: string = '100%';  
@Input() isDisabled: boolean = false;  
@Output() backClicked = new EventEmitter<void\>(); // Event emitter for parent components  
onBack() {  
if (!this.isDisabled) { // Prevent event emission if disabled  
this.backClicked.emit();  
}  
}  
}

Key Features of Our Component:

● @Input() Properties: buttonText, buttonTitle, buttonWidth, and isDisabled allow external control over the button’s appearance and behavior.

● @Output() backClicked: An EventEmitter that emits a signal when the button is clicked, enabling parent components to react.

● data-testid=”cancel”: A custom attribute specifically for testing. This is a best practice to create stable selectors that are resilient to CSS or structural changes.

● standalone: true: Simplifies module configuration, especially beneficial for component testing.

● Basic Styling: Incorporated the provided classes into component-specific styles for better encapsulation.

Step 2: The Cypress Component Test Suite (cypress/component/back-button.cy.ts)

Now, let’s create the Cypress test file dedicated to our BackButtonComponent. This file will live in a separate cypress/component directory, clearly indicating its purpose.

// cypress/component/back-button.cy.ts  
import { BackButtonComponent } from '../../src/app/back-button/back-button.component'; // Import our component  
describe('BackButtonComponent', () => {  

// Test Case 1: Default rendering and initial state  
it('should render the "Back" button with default text and be enabled', () => {  
cy.mount(BackButtonComponent); // Mount the component directly  
cy.get('\[data-testid="cancel"\]').should('be.visible')  
.and('contain.text', 'Back')  
.and('not.be.disabled');  
});  

// Test Case 2: Customizing button text  
it('should display custom button text when provided', () => {  
const customText = 'Return to Previous Screen';  
cy.mount(BackButtonComponent, { componentProperties: { buttonText: customText } });  
cy.get('\[data-testid="cancel"\]').should('contain.text', customText);  
});  

// Test Case 3: Verifying the title attribute  
it('should have a custom title attribute when provided', () => {  
const customTitle = 'Navigate back to the main dashboard';  
cy.mount(BackButtonComponent, { componentProperties: { buttonTitle: customTitle } });  
cy.get('\[data-testid="cancel"\]').should('have.attr', 'title', customTitle);  
});  

// Test Case 4: Testing the disabled state  
it('should be disabled when isDisabled input is true', () => {  
cy.mount(BackButtonComponent, { componentProperties: { isDisabled: true } });  
cy.get('\[data-testid="cancel"\]').should('be.disabled');  
});  

// Test Case 5: Emitting click event when enabled  
it('should emit backClicked event when clicked and enabled', () => {  
const onBackClickedSpy = cy.spy().as('backClickedSpy'); // Create a spy to track calls  
cy.mount(BackButtonComponent, { componentProperties: { backClicked: onBackClickedSpy } });  
cy.get('\[data-testid="cancel"\]').click();  
cy.get('@backClickedSpy').should('have.been.calledOnce'); // Assert the spy was called once  
});  

// Test Case 6: NOT emitting click event when disabled  
it('should NOT emit backClicked event when clicked and disabled', () => {  
const onBackClickedSpy = cy.spy().as('backClickedSpy');  
cy.mount(BackButtonComponent, { componentProperties: { isDisabled: true, backClicked: onBackClickedSpy } });  
cy.get('\[data-testid="cancel"\]').click({ force: true }); // Use force: true to click disabled elements  
cy.get('@backClickedSpy').should('not.have.been.called'); // Assert the spy was NOT called  
});  

// Test Case 7: Verifying CSS classes  
it('should have the expected CSS classes', () => {  
cy.mount(BackButtonComponent);  
cy.get('\[data-testid="cancel"\]')  
.should('have.class', 'btn')  
.and('have.class', 'cancel')  
.and('have.class', 'body\_b16');  
});  

// Test Case 8: Verifying inline width style  
it('should have the correct inline width style', () => {  
cy.mount(BackButtonComponent);  
cy.get('\[data-testid="cancel"\]').should('have.css', 'width', '100%');  
});  

// Test Case 9: Focusability when enabled (Accessibility)  
it('should be focusable when enabled', () => {  
cy.mount(BackButtonComponent);  
cy.get('\[data-testid="cancel"\]').focus();  
cy.get('\[data-testid="cancel"\]').should('have.focus');  
});  

// Test Case 10: Not focusable when disabled (Accessibility)  
it('should not be focusable when disabled', () => {  
cy.mount(BackButtonComponent, { componentProperties: { isDisabled: true } });  
cy.get('\[data-testid="cancel"\]').should('be.disabled');  
cy.get('\[data-testid="cancel"\]').focus({ force: true }); // Attempt to focus  
cy.get('\[data-testid="cancel"\]').should('not.have.focus'); // Should not retain focus  
});  
});

Key Aspects of the Cypress Test Suite:

● Direct Component Import: We directly import BackButtonComponent into our test file, making it clear which component is being tested.

● cy.mount(): Cypress’s powerful cy.mount() command is the heart of component testing.6 It renders the Angular component directly into the Cypress test runner’s DOM, in isolation.

● componentProperties: This object allows us to programmatically set the @Input() values of our component and mock @Output() event emitters (like backClicked) for controlled testing.

● cy.spy().as(): Cypress spies are invaluable for asserting that output events were emitted. Using .as() creates an alias for the spy, which improves readability in the Cypress Command Log.7

● Robust Selectors: Relying on data-testid=”cancel” ensures our tests are not brittle and won’t break if CSS classes or element structures change.8

● Comprehensive Coverage: The test cases cover various scenarios: default rendering, input customization, disabled states, event emission, CSS validation, and basic accessibility.

Setting Up Your Environment (if not already done):

1. Install Cypress and Angular Adapter:

npm install cypress @cypress/angular - save-dev

2. Configure cypress.config.ts:

Ensure your Cypress configuration is set up for component testing with the Angular adapter.

// cypress.config.ts  
import { defineConfig } from 'cypress';  
import { devServer } from '@cypress/angular/dist/dev-server';  
export default defineConfig({  
component: {  
devServer,  
specPattern: '\*\*/\*.cy.ts', // Or wherever your component test files are  
},  
e2e: {  
setupNodeEvents(on, config) {  
// implement node event listeners here  
},  
},  
});

3. Run Cypress:

sh npx cypress open

4. Choose “Component Testing” and select your back-button.cy.ts file to see the tests run.

Benefits of This Professional Separation:

● Clarity: It’s immediately clear what each file’s responsibility is.

● Isolation: The component can be developed and understood independently of its testing logic.

● Maintainability: Changes to the component don’t necessarily require changes to unrelated test files, and vice-versa.

● Scalability: As your application grows, this structure helps manage complexity.

● Developer Experience: Easier to navigate, faster to find relevant code, and simpler to onboard new team members.

Conclusion

Component testing is an indispensable practice for building high-quality Angular applications. By meticulously separating your component’s implementation from its Cypress test suite, you gain a powerful combination of isolation, speed, and maintainability. Our simple “Back” button example demonstrates how to write professional, comprehensive, and reliable tests that will serve as a strong foundation for your entire component library. Embrace this approach, and watch your development workflow become more efficient and your applications more robust!

Thank you for being a part of the community

By Mohamed Said Ibrahim on July 8, 2025.

Exported from Medium on October 2, 2025.

From Cypress to Playwright: Solving 5 Common Test Automation Challenges

mohamed Said Ibrahim — Thu, 02 Oct 2025 22:44:11 +0000

From Cypress to Playwright: Solving 5 Common Test Automation Challenges

Cypress is an excellent front-end testing tool, but it has certain architectural constraints that can make some real-world scenarios…

From Cypress to Playwright: Solving 5 Common Test Automation Challenges

Cypress is an excellent front-end testing tool, but it has certain architectural constraints that can make some real-world scenarios challenging.

If you’ve ever struggled with multiple user sessions, parallel execution, long test timeouts, file uploads, or network mocking in Cypress, you might be surprised to find how naturally Playwright handles these use cases.

In this guide, we’ll walk through how to address each of these problems using Playwright, with clear explanations, code examples, and best practices.

Playwright

1. Multiple User Sessions

The Cypress Challenge:

Cypress runs all tests in a single browser context by default, making it tricky to switch between different logged-in users within the same test.

The Playwright Solution:

Playwright supports multiple browser contexts out of the box, allowing completely isolated sessions that can run in the same browser instance.

Example:

import { test, expect } from '@playwright/test';  

test('Multiple user sessions in one test', async ({ browser }) => {  
  const adminContext = await browser.newContext();  
  const adminPage = await adminContext.newPage();  
  await adminPage.goto('/login');  
  await adminPage.fill('#username', 'admin');  
  await adminPage.fill('#password', 'adminPass');  
  await adminPage.click('button\[type="submit"\]');  
  await expect(adminPage).toHaveURL('/admin-dashboard');  
  const userContext = await browser.newContext();  
  const userPage = await userContext.newPage();  
  await userPage.goto('/login');  
  await userPage.fill('#username', 'user');  
  await userPage.fill('#password', 'userPass');  
  await userPage.click('button\[type="submit"\]');  
  await expect(userPage).toHaveURL('/user-dashboard');  
});

Why It’s Better:

No hacks or plugins — each context is isolated, with its own cookies, local storage, and session data.

2. Parallel Testing

The Cypress Challenge:

Parallel testing in Cypress requires the Dashboard service or manual spec splitting in CI.

The Playwright Solution:

Playwright Test natively supports parallel execution via worker processes — no external service needed.

Enabling Parallel Execution:

// playwright.config.ts

import { defineConfig } from '@playwright/test';  

export default defineConfig({  
  workers: 4, // Number of parallel workers  
});

CLI Example:

npx playwright test --workers=4

Why It’s Better:

You control parallelism locally or in CI without extra paid services, and Playwright automatically distributes tests across workers.

3. Handling Long-Running Tests (Timeouts)

The Cypress Challenge:

Cypress requires changing defaultCommandTimeout or per-command timeouts, and relies heavily on retries.

The Playwright Solution:

Playwright lets you adjust global, per-test, or per-action timeouts directly.

Global Timeout:

// playwright.config.ts

export default defineConfig({  
  timeout: 120000, // 2 minutes for each test  
});

**Per-Test Timeout:**

test('slow test', async ({ page }) => {  
  test.setTimeout(90000); // 90 seconds  
  await page.goto('/slow-page');  
});

Per-Action Timeout:

await page.click('#slow-button', { timeout: 30000 });

Why It’s Better:

You have fine-grained control over timeouts without changing framework-wide behavior.

4. Uploading Files

The Cypress Challenge:

File uploads require installing cypress-file-upload or similar plugins.

The Playwright Solution:

File upload support is built-in with setInputFiles().

Example:

test('File upload', async ({ page }) => {  
  await page.goto('/upload');  
  await page.setInputFiles('input\[type="file"\]', 'tests/fixtures/sample.pdf');  
  await page.click('#upload-button');  
  await expect(page.locator('#upload-success')).toBeVisible();  
});

Why It’s Better:

No plugins, no extra configuration — works for both single and multiple files, and supports drag-and-drop via locator targeting.

5. Network Requests: `cy.request()` vs `cy.intercept()`

The Cypress Challenge:

cy.request() is used for direct API calls.
cy.intercept() is for mocking/spying on network calls. Both require different syntaxes and contexts.

The Playwright Solution:

Playwright combines network interception and direct HTTP requests in a unified, flexible API.

Direct API Request (like **cy.request()**):

const apiContext = await request.newContext();  
const response = await apiContext.post('/api/login', {  
  data: { username: 'admin', password: 'adminPass' }  
});  
expect(response.status()).toBe(200);

**Intercept and Mock (like** `**cy.intercept()**`**):**

await page.route('\*\*/api/items', route => {  
  route.fulfill({  
    status: 200,  
    contentType: 'application/json',  
    body: JSON.stringify(\[{ id: 1, name: 'Mocked Item' }\]),  
  });  
});  

await page.goto('/items');  
await expect(page.locator('.item')).toHaveText('Mocked Item');

Why It’s Better:

Playwright lets you intercept, modify, or mock before the request is made, with full control over timing and response.

Final Thoughts

For developers migrating from Cypress to Playwright, these five areas — sessions, parallelism, timeouts, file uploads, and network control — show just how much flexibility Playwright offers out of the box.

Quick Comparison Table:

Quick Comparison Table

By mastering these Playwright features, you’ll handle complex automation scenarios more efficiently and with cleaner, more maintainable code.

You have read about: Playwright vs Cypress, Playwright multiple user sessions, Playwright parallel testing, Playwright timeouts, Playwright file upload, Playwright API testing, Playwright network mocking, Cypress limitations Playwright solutions.

And before you go, don’t forget to clap and follow the writer️!

By Mohamed Said Ibrahim on August 16, 2025.

Exported from Medium on October 2, 2025.

Mastering Cypress Retries: How to Efficiently Re-Run Only Failed Tests with Mochawesome & Dynamic…

mohamed Said Ibrahim — Thu, 02 Oct 2025 22:41:27 +0000

Mastering Cypress Retries: How to Efficiently Re-Run Only Failed Tests with Mochawesome & Dynamic…

Cypress, Failed Tests, Test Retries, Mochawesome, CI/CD, Test Automation, Node.js, @cypress/grep, ENAMETOOLONG, E2E Testing, Quality…

Mastering Cypress Retries: How to Efficiently Re-Run Only Failed Tests with Mochawesome & Dynamic Configuration

Cypress, Failed Tests, Test Retries, Mochawesome, CI/CD, Test Automation, Node.js, @cypress/grep, ENAMETOOLONG, E2E Testing, Quality Assurance, Test Optimization

Introduction: The Frustration of Flaky Tests

In the world of End-to-End (E2E) testing, nothing is more frustrating than a flaky test. One moment it passes, the next it fails, often due to transient environmental issues, network latency, or asynchronous timing. Rerunning your entire Cypress test suite every time a few tests fail is a significant time sink, especially in large projects and demanding CI/CD pipelines.

What if you could pinpoint exactly which tests failed, gather their full titles and original spec files, and then execute only those specific tests? Imagine the time savings, the faster feedback loops, and the sheer efficiency!

This article will guide you through building a robust, automated solution using Cypress, Mochawesome reports, Node.js scripting, and the powerful @cypress/grep plugin. We'll cover:

Generating Rich Reports: Leveraging Mochawesome to get detailed test results.
Extracting Failed Test Data: A Node.js script to parse Mochawesome reports and collect failed test titles and their corresponding spec files.
Dynamic Cypress Execution: Modifying Cypress’s configuration on-the-fly to precisely target only the collected failed tests, bypassing command-line length limitations (e.g., ENAMETOOLONG errors).
Cache Clearing & Data Cleaning: Best practices for maintaining a clean test environment.

Let’s transform your Cypress test recovery strategy from a time-consuming chore into a streamlined, automated process.

Failed Tests

Step 1: Setting Up Mochawesome for Comprehensive Reporting

Mochawesome is a beautiful, interactive, and highly customizable reporter for Mocha (and thus Cypress, which uses Mocha under the hood). It’s essential for getting the detailed data we need to identify failed tests.

1. Install Mochawesome and its Cypress Adapter:

npm install \--save-dev mochawesome mochawesome-merge mochawesome-report-generator

# or

yarn add \--dev mochawesome mochawesome-merge mochawesome-report-generator

2. Configure **cypress.config.ts** for Mochawesome:

Your cypress.config.ts (or .js) needs to tell Cypress to use Mochawesome and merge the reports if you're running tests across multiple spec files.

// cypress.config.ts  
import { defineConfig } from 'cypress';  

export default defineConfig({  
  e2e: {  
    setupNodeEvents(on, config) {  
      // Required for Mochawesome to merge reports correctly  
      on('after:run', async (details) => {  
        if (details.runs) {  
          const { merge } = require('mochawesome-merge');  
          const { generate } = require('mochawesome-report-generator');  
          // Collect all mochawesome JSON files  
          const mochawesomeJsonFiles = details.runs.map(run =>  
            run.results && run.results.length > 0 ? run.results[0].reporterStats.reportFilename : null  
          ).filter(Boolean); // Filter out nulls  
          if (mochawesomeJsonFiles.length > 0) {  
            const mergedReport = await merge(mochawesomeJsonFiles);  
            await generate(mergedReport, {  
              reportDir: 'cypress/reports/mochawesome', // Output directory for the HTML report  
              reportFilename: 'combined-report', // Name of the HTML report file  
              overwrite: true,  
              json: true, // Keep the merged JSON file  
            });  
          }  
        }  
      });  
      return config;  
    },  
  },  
  reporter: 'mochawesome',  
  reporterOptions: {  
    reportDir: 'cypress/reports/mochawesome-json', // Where individual JSON reports go  
    overwrite: false, // Don't overwrite individual JSONs  
    html: false, // Don't generate HTML for individual JSONs  
    json: true, // Generate JSON for individual runs  
  },  
});

Now, after each cypress run, you'll find individual JSON reports in cypress/reports/mochawesome-json and a combined HTML report with its corresponding JSON in cypress/reports/mochawesome.

Step 2: Extracting Failed Test Data from Mochawesome Reports

This is where the magic begins. We’ll write a Node.js script to read the combined Mochawesome JSON report, identify failed tests, and extract their full titles and spec file paths. This data will be saved to a failed-tests.json file.

Create **extract-failed-tests.js**:

// extract-failed-tests.js  
const fs = require('fs');  
const path = require('path');  

const combinedReportPath = path.join(__dirname, 'cypress', 'reports', 'mochawesome', 'combined-report.json');  
const outputFailedTestsPath = path.join(__dirname, 'cypress', 'temp', 'failed-tests.json');  
const failedTestsData = {  
  failedTitles: [],  
  specsToRun: [],  
};  
try {  
  if (!fs.existsSync(combinedReportPath)) {  
    console.warn(`Warning: Mochawesome combined report not found at ${combinedReportPath}. No failed tests extracted.`);  
    process.exit(0);  
  }  
  const report = JSON.parse(fs.readFileSync(combinedReportPath, 'utf8'));  
  const specsSet = new Set(); // Use a Set to store unique spec paths  
  report.results.forEach(suiteResult => {  
    suiteResult.suites.forEach(suite => {  
      suite.tests.forEach(test => {  
        if (test.fail) {  
          let fullTitle = test.fullTitle;  
          // Clean up the fullTitle by removing extra spaces or unwanted characters  
          fullTitle = fullTitle.replace(\s+/g, ' ').trim(); // Replace multiple spaces with single space  
          // Store the full title  
          failedTestsData.failedTitles.push(fullTitle);  
          // Extract the spec path from the suite file property  
          if (suite.file) {  
            // Ensure path is relative and correctly formatted for Cypress  
            const relativeSpecPath = path.relative(process.cwd(), suite.file).replace(/g, '/');  
            specsSet.add(relativeSpecPath);  
          }  
        }  
      });  
    });  
  });  
  failedTestsData.specsToRun = Array.from(specsSet);  
  // Ensure the output directory exists  
  fs.mkdirSync(path.dirname(outputFailedTestsPath), { recursive: true });  
  fs.writeFileSync(outputFailedTestsPath, JSON.stringify(failedTestsData, null, 2), 'utf8');  
  console.log(`Successfully extracted ${failedTestsData.failedTitles.length} failed tests.`);  
  console.log(`Failed tests manifest saved to: ${outputFailedTestsPath}`);  
} catch (error) {  
  console.error(`Error extracting failed tests: ${error.message}`);  
  process.exit(1);  
}

How it works:

It reads combined-report.json generated by Mochawesome Merge.
It iterates through all test results, identifies test.fail cases.
For each failed test, it captures the test.fullTitle (which includes parent describe blocks) and the suite.file (the spec path).
It stores unique spec paths in a Set to avoid duplicates and writes the final failed-tests.json.

Step 3: Dynamic Cypress Re-Run with `@cypress/grep` and Configuration Injection

This is the core of our solution to efficiently re-run only the identified failed tests, addressing the ENAMETOOLONG error. We'll use @cypress/grep for intelligent test filtering and dynamically inject its parameters directly into cypress.config.ts.

1. Install and Configure **@cypress/grep**:

npm install -D @cypress/grep

# or

yarn add -D @cypress/grep

**cypress.config.ts** modifications (crucial for dynamic injection):

// cypress.config.ts  
import { defineConfig } from 'cypress';  
import registerCypressGrep from '@cypress/grep/src/plugin'; // Note: /src/plugin for TS  

export default defineConfig({  
  e2e: {  
    setupNodeEvents(on, config) {  
      registerCypressGrep(config); // Register the plugin  
      // --- START_DYNAMIC_CYPRESS_CONFIG_INJECTION ---  
      // This section will be managed by run-failed-tests.js  
      // DO NOT MANUALLY EDIT BETWEEN THESE MARKERS!  
      // --- END_DYNAMIC_CYPRESS_CONFIG_INJECTION ---  
      // Override specPattern if dynamically provided by our script  
      if (config.env.CYPRESS_GREP_SPEC_PATTERN) {  
        config.specPattern = config.env.CYPRESS_GREP_SPEC_PATTERN;  
        console.log(`Cypress config: Using dynamic specPattern: ${config.specPattern}`);  
      }  
      // Important: Add Mochawesome setup here as well if not already present from Step 1  
      on('after:run', async (details) => {  
        if (details.runs) {  
          const { merge } = require('mochawesome-merge');  
          const { generate } = require('mochawesome-report-generator');  
          const mochawesomeJsonFiles = details.runs.map(run =>  
            run.results && run.results.length > 0 ? run.results\[0\].reporterStats.reportFilename : null  
          ).filter(Boolean);  
          if (mochawesomeJsonFiles.length > 0) {  
            const mergedReport = await merge(mochawesomeJsonFiles);  
            await generate(mergedReport, {  
              reportDir: 'cypress/reports/mochawesome',  
              reportFilename: 'combined-report',  
              overwrite: true,  
              json: true,  
            });  
          }  
        }  
      });  
      return config;  
    },  
    specPattern: 'cypress/e2e/***.cy.{js,jsx,ts,tsx}', // Default spec pattern  
  },  
  reporter: 'mochawesome',  
  reporterOptions: {  
    reportDir: 'cypress/reports/mochawesome-json',  
    overwrite: false,  
    html: false,  
    json: true,  
  },  
});

**cypress/support/e2e.ts** (for **@cypress/grep** to work in the browser):

// cypress/support/e2e.ts  
import '@cypress/grep'; // Import for side-effects. Do NOT expect a default export here.  
// You can also add other global commands or setups here  
// import './commands';

2. Create **run-failed-tests.js**:

This script will read failed-tests.json, inject the filtering data into cypress.config.ts, run Cypress, and then clean up the cypress.config.ts.

// run-failed-tests.js  
const fs = require('fs');  
const path = require('path');  
const { execSync } = require('child\_process');  

const failedTestsFilePath = path.join(__dirname, 'cypress', 'temp', 'failed-tests.json');  
const cypressConfigPath = path.join(__dirname, 'cypress.config.ts'); // Or .js if applicable  
let originalCypressConfigContent = ''; // Stores content to restore  
function deleteContentBetweenMarkers(fileContent, startMarker, endMarker) {  
  const startIndex = fileContent.indexOf(startMarker);  
  const endIndex = fileContent.indexOf(endMarker);  
  if (startIndex === -1 || endIndex === -1 || startIndex >= endIndex) {  
    console.warn(`Markers not found or out of order for cleanup. Proceeding without specific content deletion.`);  
    return fileContent; // Return original content if markers are missing  
  }  
  return fileContent.substring(0, startIndex + startMarker.length) +  
         '\n' + // Keep the markers on separate lines  
         fileContent.substring(endIndex);  
}  
try {  
  // Read failed tests data  
  const failedTestsData = JSON.parse(fs.readFileSync(failedTestsFilePath, 'utf8'));  
  const failedTitles = failedTestsData.failedTitles;  
  const specsToRun = failedTestsData.specsToRun;  
  if (!failedTitles || failedTitles.length === 0) {  
    console.log('No failed test titles found in failed-tests.json. Exiting.');  
    process.exit(0);  
  }  
  // Prepare values for injection  
  const grepTitles = failedTitles.join(';');  
  const dynamicSpecPattern = specsToRun.map(p => p.replace(\\/g, '/')); // Normalize paths  
  // Read original config content  
  originalCypressConfigContent = fs.readFileSync(cypressConfigPath, 'utf8');  
  // Prepare content to inject between markers  
  let injectedContent = `  
      // Injected by run-failed-tests.js  
      config.env.grep = ${JSON.stringify(grepTitles)};  
      config.env.grepFilterSpecs = true; // Optimize grep filtering  
  `;  
  if (dynamicSpecPattern.length > 0) {  
    injectedContent += `  
      config.env.CYPRESS_GREP_SPEC_PATTERN = ${JSON.stringify(dynamicSpecPattern)};  
    `;  
  } else {  
    // If no specific specs, ensure this env var is not set to default to cypress.config.ts's specPattern  
    injectedContent += `  
      delete config.env.CYPRESS\_GREP\_SPEC\_PATTERN;  
    `;  
  }  
  // Inject content into config  
  const startMarker = '// --- START\_DYNAMIC\_CYPRESS\_CONFIG\_INJECTION ---';  
  const endMarker = '// --- END\_DYNAMIC\_CYPRESS\_CONFIG\_INJECTION ---';  
  const startIndex = originalCypressConfigContent.indexOf(startMarker);  
  const endIndex = originalCypressConfigContent.indexOf(endMarker);  
  if (startIndex === -1 || endIndex === -1 || startIndex >= endIndex) {  
    console.error(`Error: Dynamic injection markers not found in '${cypressConfigPath}'.`);  
    console.error(`Please ensure your cypress.config.ts contains '${startMarker}' and '${endMarker}' within setupNodeEvents.`);  
    process.exit(1);  
  }  
  const beforeInjection = originalCypressConfigContent.substring(0, startIndex + startMarker.length);  
  const afterInjection = originalCypressConfigContent.substring(endIndex);  
  const modifiedConfigContent = beforeInjection + injectedContent + afterInjection;  
  fs.writeFileSync(cypressConfigPath, modifiedConfigContent, 'utf8');  
  console.log('Temporarily updated cypress.config.ts with test filters.');  
  // Run Cypress  
  console.log(`Executing Cypress re-run...`);  
  execSync(`npx cypress run`, { stdio: 'inherit' }); // No --spec or --env needed on CLI  
  console.log('\nCypress re-run of failed tests completed.');  
} catch (error) {  
  console.error(`Error during failed test re-run: ${error.message}`);  
  process.exit(1);  
} finally {  
  // Restore original config content (CRITICAL for clean state)  
  if (originalCypressConfigContent) {  
    console.log('Restoring original cypress.config.ts...');  
    const contentToRestore = deleteContentBetweenMarkers(originalCypressConfigContent, startMarker, endMarker);  
    fs.writeFileSync(cypressConfigPath, contentToRestore, 'utf8');  
    console.log('Restored cypress.config.ts to clean state.');  
  }  
}

Step 4: Cache Clearing and Data Cleaning (Best Practices)

Maintaining a clean environment is crucial for reliable test runs.

1. Cypress Cache Clearing:

Cypress maintains a cache of downloaded binaries. Clearing it can resolve issues, especially after updates or corruption.

npx cypress cache clear

2. Data Cleaning (Application Under Test):

This is highly application-specific, but generally, before re-running failed tests, you want your application’s state to be as clean and consistent as possible. This often involves:

Database Seeding/Truncation: Resetting your database to a known state.
API Calls: Using API calls to delete or reset data created by previous tests.
UI Resets: Ensuring your application’s UI is back to a default state (e.g., logging out, clearing local storage).

Integrate these cleaning steps into your package.json scripts or a separate Node.js script.

Step 5: Orchestrating the Workflow

Now, let’s put it all together in your package.json scripts for an easy-to-use workflow.

// package.json  
{  
  "name": "cypress-failed-tests-rerun",  
  "version": "1.0.0",  
  "description": "Cypress project with failed test re-run capability",  
  "main": "index.js",  
  "scripts": {  
    "test:full": "npm run clean:reports && npx cypress run",  
    "test:failed": "npm run clean:reports && npx cypress run && npm run extract:failed && npm run run:failed",  
    "extract:failed": "node extract-failed-tests.js",  
    "run:failed": "node run-failed-tests.js",  
    "clean:reports": "npx rimraf cypress/reports cypress/temp && echo 'Cleaned reports and temp directories'",  
    "cypress:open": "npx cypress open",  
    "cypress:cache:clear": "npx cypress cache clear"  
  },  
  "devDependencies": {  
    "@cypress/grep": "^3.0.0",  
    "cypress": "^13.0.0", // Use your Cypress version  
    "mochawesome": "^7.1.3",  
    "mochawesome-merge": "^4.3.0",  
    "mochawesome-report-generator": "^6.2.0",  
    "rimraf": "^5.0.0", // For cross-platform directory deletion  
    "typescript": "^5.0.0" // If using TypeScript  
  }  
}

Workflow Explanation:

npm run test:full: Runs your entire Cypress suite.
npm run test:failed:
clean:reports: Clears previous reports.
npx cypress run: Runs the full suite (you could adjust this to run fewer tests initially if you have a known set of flaky ones).
extract:failed: Parses the Mochawesome report to find failed tests.
run:failed: Executes the Node.js script to dynamically configure Cypress and re-run only the identified failed tests.

Conclusion: A Smarter Approach to Cypress Test Execution

By integrating Mochawesome reporting, dynamic configuration injection with @cypress/grep, and a well-structured Node.js workflow, you've gained an incredibly powerful tool for managing test failures. No more wasted CI/CD minutes rerunning entire suites for a few flaky tests. This approach not only optimizes your testing pipeline but also contributes to a smoother, more efficient development experience.

Embrace this advanced strategy and spend less time waiting for tests and more time building amazing software!

By Mohamed Said Ibrahim on July 24, 2025.

Exported from Medium on October 2, 2025.

Forem: mohamed Said Ibrahim

The Complete Guide to Testing React & Next.js Applications with Cypress

The Complete Guide to Testing React & Next.js Applications with Cypress

The Complete Guide to Testing React & Next.js Applications with Cypress

Why Cypress for React & Next.js Testing?

1. Setting Up Cypress for React & Next.js

Installation

Folder Structure

Configuring cypress.config.js for Next.js

2. Testing React Components with Cypress

Component Testing (Cypress + React)

3. Handling Dynamic Content & API Calls

Mocking API Responses

4. Solving Common React Testing Challenges

A. State Management Issues

B. Next.js Routing & SSR Challenges

C. Flaky Tests Due to Rendering Delays

5. Advanced Cypress Strategies for React/Next.js

A. Visual Regression Testing

B. Running Tests in CI/CD (GitHub Actions Example)

C. Cross-Browser Testing

Final Checklist for React/Next.js Testing with Cypress

Conclusion

Further Reading

React #NextJS #Cypress #Testing #Automation #WebDev #FrontEnd

Core Technical Topics to Master in Cypress for Effective E2E Testing

Core Technical Topics to Master in Cypress for Effective E2E Testing

Core Technical Topics to Master in Cypress for Effective E2E Testing

1. Writing Cypress Tests (Selectors, Commands, Assertions)

Selectors

Commands & Assertions

2. Page Object Model (POM) in Cypress

3. Handling API Requests & Network Interception

cy.request() for API Testing

cy.intercept() for Mocking & Stubbing

4. Running Tests on Different Viewports/Devices

5. Handling Test Flakiness & Retries

Causes of Flakiness:

Solutions:

6. Using Cypress with GitHub/GitLab CI

GitHub Actions Example:

Example Question: Structuring Cypress Tests for a Large React App

Conclusion

Further Reading:

Cypress #Testing #QA #Automation #WebDevelopment #JavaScript #ContinuousIntegration

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

Conquering Cypress Test Failures: A Comprehensive Guide to Common Errors & Automated Reporting

The Unavoidabnode generate_failed_tests_report.jsle Truth: Understanding Common Cypress Test Failures

🔴 Critical Priority Failures: Stop Everything!

🟠 High Priority Failures: Application Under Test isn’t Behaving!

🟡 Medium Priority Failures: Interactivity & Timing Issues

⚫ Other/Unknown Priority Failures

Beyond the Red: Introducing the Cypress Failed Tests Report Generator

The Objective of generate_failed_tests_report.js

How It Works: A Deep Dive into the Script’s Anatomy

Key Benefits of Using the Script:

Getting Started with Your Automated Report Generator

Customizing Error Categorization

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing cypress-angular-commands

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing cypress-angular-commands

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing cypress-angular-commands

✅ Why You Should Read This

🚀 Meet cypress-angular-commands

🎯 What Makes It Special?

📚 Coverage You Can Count On

🛠 Install and Set Up in Seconds

🔍 Real Example: Clean, Readable, Robust

🧪 Built for:

💼 Use Cases in the Wild

🔐 Safe for Existing Projects

👨‍💻 About the Author

📈 You have read about:

❤️ Final Words

🔐 Supercharge Your Test Stability with cy.ensurePageIsReady() in Cypress.io

🔐 Supercharge Your Test Stability with cy.ensurePageIsReady() in Cypress.io

🔐 Supercharge Your Test Stability with cy.ensurePageIsReady() in Cypress.io

🚀 Why cy.ensurePageIsReady() Is a Game-Changer

✅ What It Does (Behind the Scenes)

1️⃣ Network Silence Detection

Configuring `cypress.config.js` for Next.js

`cy.request()` for API Testing

`cy.intercept()` for Mocking & Stubbing

The Unavoidab`node generate_failed_tests_report.js`le Truth: Understanding Common Cypress Test Failures

The Objective of `generate_failed_tests_report.js`

🔥 Supercharge Your Angular E2E Testing with Cypress — Introducing `cypress-angular-commands`

🚀 Meet `cypress-angular-commands`

🔐 Supercharge Your Test Stability with `cy.ensurePageIsReady()` in Cypress.io

🚀 Why `cy.ensurePageIsReady()` Is a Game-Changer