Forem: Cypress

How I stopped declaring login in each of my 5k tests

Marcelo C. — Fri, 27 Feb 2026 19:26:44 +0000

Have you ever encountered a testing codebase that many portions are repeated over and over? We all have! Of course, I could be talking about DRY princples (Don't Repeat Yourself), but lets keep that aside for now and focus on a Cypress trick up it's sleeve that can go unnoticed for many senior devs: the global hooks.

And what do I mean by "global" hooks? They're called like that because you only declare them once and they're applied to all your tests instantly.

So let's get to the grain here: when installing Cypress it already comes with a file at created at cypress/support/e2e.<ts|js> level. This is usually where you declare some important commands imports that your E2E testing will need to access and run properly.

But it's also responsible for adding let's say before, beforeEach, or after, afterEach hooks that will be applied by all your tests. This can be responsible for login hooks, clean-ups to the database after the tests run, screenshots resolutions configuration -- a million of possibilities here.

I guess that the "global hooks" makes more sense now, right?

The challenge

At my workplace, I encountered the command to login, called cy.login, declared in each of the 5.634 tests that we have. For a while it bothered me a lot, because I always wanted to remove this codelines, and make my life easier with a simple e2e.ts file that handled all existing and new login logic for future tests.

But if I knew how it worked, why didn't I just do it already?

Becuase, for the first time (for me), I was dealing with a really complex system: a big chunk of the legacy tests ran with testIsolation: false. That meant that they only login once, and the it blocks don't load a new baseURL after each one is done. They do it all in one session.

Because? Well, that would be another story, so let's just accept their done like that for "system requirements" at the time.

Ok, so I basically needed:

before() → cy.login() beforeEach() → cy.login() only if testIsolation is true

Easy right? Not yet. The complexity resides because different spec families have different needs: different credentials, different environments, different session strategies, and different testIsolation settings.

There are two needs here to login:

Which login method?

cy.login(): Default specs with standard app with default credential.
cy.loginDemo(): Presentation specs with different environment, likely SSO or different credentials.
Custom (own login): Need specific credentials or totally different E2E tests outside enviroment.

When to login? (before vs beforeEach)

This is driven by Cypress's testIsolation setting:

testIsolation: true — Cypress clears browser state (cookies, storage) between each test. Session is lost → must re-login before each test.
testIsolation: false — Cookies persist across tests in the same spec → login once is enough.

Now, here is where the plot thickens. I had to declare folders, tests, paths that needed to be skipped (or not), because on the same folder I had testIsolation: true/false. So, follow me along:

1. Legacy specs (/legacy/ folder)

before() → skip entirely
beforeEach() → only call cy.login() if testIsolation is true

Legacy specs use specific credentials. If the global before() called cy.login() first, cy.session() would cache the wrong credentials, causing 500 errors when the spec then tries to login with different ones. So global before() is completely skipped. In beforeEach(), it only re-validates when state is actually cleared (testIsolation: true).

2. Training portal specs (/training/ folder) + Custom login specs

before() → skip entirely
beforeEach() → skip entirely

These specs manage their own login end-to-end. The global hooks stay completely out of the way. Some tests likely test login flows themselves or use role-specific credentials.

3. BEFORE_LOGIN_DEMO_SPECS

before() → cy.loginDemo() + cy.goToHome()
beforeEach() → skip (already logged in)

Login once per spec, reused across all tests. These are demo/presentation specs where re-logging in per test would be slow and unnecessary.

4. BEFORE_EACH_LOGIN_DEMO_SPECS

before() → nothing
beforeEach() → cy.loginDemo() + cy.goToHome()

Similar to above but login is repeated per test because testIsolation: true, the state is cleared between tests, so they must re-login each time.

5. LOGIN_DEMO_SPECIAL_SPECS

before() → nothing
beforeEach() → override baseUrl + timeout + idp_active env, then cy.loginDemo()

This spec runs against a completely different server, with an IDP/SSO active flag and a much longer timeout. The config must be set before each test because test isolation may reset Cypress config state.

6. Default specs (everything else, A.K.A the MOST important logic!)

before() → cy.login()
beforeEach() → cy.login() only if testIsolation is true

Standard app, default credentials. Login once in before(), then beforeEach() only re-validates the session if Cypress actually cleared it (testIsolation: true). If testIsolation is false, cookies persist and calling cy.login() again would navigate back to home, breaking any test that expects to be on a specific page.

The key insight: why before AND beforeEach?

You're asking "are you mental? why on earth would you declare login TWICE?", basically because:

before() → establishes the initial session (runs once)
beforeEach() → re-validates/restores the session if testIsolation cleared it

For specs with testIsolation: false, beforeEach() is a no-op (or returns early) because the session is still alive. For specs with testIsolation: true, beforeEach() must re-run the login to restore the cleared session — but it uses cy.session() internally which caches credentials.

Here's a sneak peek of how my e2e.ts file looks in it's (hopefully) final form:

And I basically removed the cy.login function from more than 1k files in my codebase, leaving me or any other engineer to not worry anymore about the login being declared at test level, it handles everything for me now, as it should.

What about you? Have you ever encountered a challenging and complex test codebase to deal with? What was the most difficult change you had to make? Leave me a comment, I would love to hear!

Cypress in the Age of AI Agents: Orchestration, Trust, and the Tests That Run Themselves

Vladimir Mikhalev — Thu, 26 Feb 2026 11:33:21 +0000

Last year, I wrote about Docker and Cypress for this blog. It covered containers, layer caching, and parallel runners. Good stuff. Useful stuff.

But I'm not writing that article again.

Here's why.

I could write a perfect container config in my sleep. So could Claude. So could GPT. So could any intern with a prompt. Syntax has become a commodity. The Dockerfile isn't the hard part anymore.

The hard part?

Orchestration and trust when AI agents run the tests.

Let me explain.

The Shift Nobody Talks About

In 2025, Cypress shipped cy.prompt(). Write tests in plain English. The AI figures out the selectors. It even self-heals when your UI changes.

That's powerful. And that's dangerous.

Not because the tool is bad. It's genuinely impressive. But because it changes who is making decisions in your pipeline. And most teams haven't thought about that.

Before cy.prompt(), the chain of trust was simple:

A human wrote the test
A human reviewed it
CI ran it
If it failed, a human fixed it

Every link in that chain had a name attached.

Now?

An AI writes the test
An AI picks the selectors
An AI heals the test when it breaks
The human sees green checkmarks
Everybody ships

Until something goes wrong. And nobody knows why.

Autonomy vs. Augmentation: The Framework That Matters

The industry keeps confusing two very different things.

Autonomy means the agent acts for you. You find out later what happened.
Think: self-driving car. You're the passenger. The AI makes every turn.

Augmentation means the agent helps you decide. You still make the call.
Think: GPS navigation. It suggests the route. You drive.

Most AI testing tools sell autonomy:

"Never write a test again!"
"Self-healing pipelines!"
"Zero maintenance!"

That sounds great in a demo.

It falls apart in production.

Google's testing team found that 1.5% of all test runs were flaky (2016 study). Nearly 16% of tests showed some flakiness over time. Microsoft reported 49,000 flaky tests across 100+ product teams (2022). These numbers haven't gotten better. Now imagine those tests were written by AI.

You don't have a testing problem.

You have a trust problem.

What Actually Happens When AI Writes Your Cypress Tests

I've watched AI code assistants generate test suites. Here's the pattern I see every time:

Day one: Beautiful. High coverage numbers. Clean syntax. The PR merges fast. Everyone celebrates.

Week two: A UI change breaks three tests. The self-healing kicks in. Tests pass again. Nobody checks what changed.

Month two: The self-healed selectors are now targeting the wrong elements. The tests pass. But they're testing the wrong things. Your coverage number says 90%. Your real coverage is closer to 40%.

Quarter end: A production bug ships. The test suite was green. The post-mortem reveals the AI "healed" a critical login test. It now clicks a decorative button instead of the submit button. Both are blue. Both say "Continue."

The AI didn't fail.

The architecture failed.

Nobody designed a system where AI decisions get verified.

The Architecture Cypress Teams Actually Need

Here's the playbook I'd build for any team using Cypress with AI in 2026.

Layer 1: AI Generates, Humans Gate

Use cy.prompt() (or any AI tool) to draft tests. That's the accelerator.

But treat AI-generated tests like pull requests from a junior developer.

// cy.prompt() generates the test
cy.prompt([
  'Visit the login page',
  'Type admin@company.com into the email field',
  'Type the password into the password field',
  'Click the sign in button',
  'Verify the dashboard loads'
])

Then eject that code. Review the selectors. Commit the explicit version.

// The reviewed, committed version
cy.visit('/login')
cy.get('[data-cy=email]').type('admin@company.com')
cy.get('[data-cy=password]').type(Cypress.env('TEST_PASSWORD'))
cy.get('[data-cy=submit-login]').click()
cy.url().should('include', '/dashboard')
cy.get('[data-cy=welcome-banner]').should('be.visible')

The AI got you there faster. A human verified the result.

That's augmentation.

Layer 2: The Trust Boundary in CI

Your pipeline needs a clear line:

On one side: things AI can do alone
On the other: things that need human eyes

# GitHub Actions - Trust Architecture
jobs:
  ai-generated-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Run AI-assisted test suite
        run: |
          docker compose -f docker-compose.cypress.yml up \
            --abort-on-container-exit \
            --exit-code-from cypress

      - name: Validate no self-healed selectors
        run: |
          # Flag any tests that healed since last commit
          # Note: Requires a custom script to parse
          # Cypress Cloud API or stdout logs
          node ./scripts/check-healed-tests.js
          # If selectors changed, block the merge
          # Force a human review

      - name: Screenshot diff on healed tests
        if: failure()
        run: |
          # Capture what the AI "fixed"
          # Attach to PR for human review
          npx cypress run --spec "healed-tests/**" \
            --config screenshotOnRunFailure=true

The key:

Self-healed tests don't auto-merge. They create a review request. A human looks at what changed. Then decides.

Layer 3: The Accountability Layer

Every AI decision in your pipeline needs a log.

Not just "test passed."

But: "test healed selector from .btn-primary to .btn-action on Feb 15."

// cypress.config.js
module.exports = {
  e2e: {
    experimentalPromptCommand: true,
    setupNodeEvents(on, config) {
      on('after:spec', (spec, results) => {
        // Parse Cypress stdout or Cloud API for healing events.
        // Self-healing data appears in the Command Log
        // but isn't yet exposed in results.stats.
        //
        // Option A: Parse terminal output for "Self-Healed" tags
        // Option B: Query Cypress Cloud API for spec run details
        // Option C: Build a custom Cypress plugin that listens
        //           to command events during the run

        const healingEvents = parseHealingFromLogs(spec.name)

        if (healingEvents.length > 0) {
          logToAuditTrail({
            spec: spec.name,
            healed: healingEvents.length,
            timestamp: new Date().toISOString(),
            details: healingEvents
          })
        }
      })
    }
  }
}

When something breaks in production, you can trace it back:

"The AI changed this selector on this date. Nobody reviewed it. That's the gap."

Without this layer, your pipeline is a black box.

Green doesn't mean correct. It means unchallenged.

Layer 4: Docker as the Trust Container

Docker isn't just for consistency anymore.

It's your isolation boundary for AI-generated tests.

# docker-compose.cypress.yml
services:
  cypress-human-authored:
    build:
      context: .
      dockerfile: Dockerfile.cypress
    command: >
      npx cypress run
      --spec "cypress/e2e/human-authored/**"
    volumes:
      - ./results/human:/results

  cypress-ai-generated:
    build:
      context: .
      dockerfile: Dockerfile.cypress
    command: >
      npx cypress run
      --spec "cypress/e2e/ai-generated/**"
    volumes:
      - ./results/ai:/results
    # AI tests run in a separate container
    # Different reporting, different trust level

Separate the results. Report them differently.

Human-authored tests are your source of truth
AI-generated tests are your early warning system

When both agree: high confidence.
When they disagree: investigate.
When only AI tests pass: be suspicious.

The Uncomfortable Question

Here's where I need to be honest.

I've been in tech for 20 years, and spent the last 15 building delivery pipelines. I can debug a failing Docker container at 2 AM with my eyes half closed. I've configured CI/CD systems that run thousands of tests across dozens of services.

And I'm watching AI tools do parts of that job faster than I can.

That's not a threat.

That's a signal.

The value isn't in writing the cy.get() selector anymore.

The value is in designing the system where:

AI-generated selectors get verified
Self-healing gets audited
Trust has a paper trail

The Executor writes the test.

The Architect designs the trust system.

Most teams are building AI-powered testing without building AI-accountable testing. They're adding speed without adding trust.

That's technical debt with a new name.

What I'd Do This Week

If I ran a Cypress team today, here's my Monday morning plan:

Separate your test suites. Human-authored in one folder. AI-generated in another. Track them separately.
Add an audit log for self-healing. Every time cy.prompt() (or any AI tool) changes a selector, log it. Make it visible.
Block auto-merge on healed tests. Self-healed tests go into a review queue. A human approves. Every time.
Run AI tests in a separate Docker container. Different reporting pipeline. Compare results against human-authored tests.
Measure real coverage. Not line coverage. Not selector coverage. "Does this test actually verify the behavior we care about?" AI can inflate coverage numbers without testing anything meaningful.

None of this is anti-AI.

All of this is pro-trust.

The Bottom Line

Cypress + AI is the future. I believe that. cy.prompt() is a genuine leap forward.

The ability to write tests in plain English, the self-healing, the lower barrier to entry — all of it matters.

But the teams that win won't be the ones who automate the most.

They'll be the ones who trust the right things and verify everything else.

The bot that ships the wrong build doesn't get fired. You do.

Design accordingly.

Resources:

Valdemar is a Docker Captain and Cypress Ambassador based in Canada. He builds CI/CD pipelines that don't lie to you. Find him at valdemar.ai.

Leading Quality Through Change: Balancing Speed, AI, and the Fundamentals That Matter

Ronald Williams — Thu, 29 Jan 2026 16:41:46 +0000

As software delivery accelerates and AI driven tooling reshapes how teams approach testing, many QA leaders are facing the same challenge: how to evolve quality practices without losing the fundamentals that keep teams effective, scalable, and trusted.

This tension shows up in real leadership decisions every day. framework selection, automation trade offs, skill development, and responsible adoption of emerging tools. The conversations are rarely just about tools. They are about judgment, mindset, and how to guide teams through constant change without sacrificing long term quality.

In this reflection, Lyle Smart, Director of Quality Assurance and Test Automation (SDET) at Continued, shares perspective shaped by real world leadership decisions. His experience offers practical guidance for QA and engineering leaders navigating speed, complexity, and sustainability in today’s delivery landscape.

When a technical decision becomes a leadership one

One defining moment for Lyle came during a new platform build, when he was faced with choosing a test automation framework.

On the surface, the decision appeared technical. In reality, it carried significant leadership weight.

That choice would influence how the team collaborated, how quickly engineers could onboard, and how quality practices would scale over time. For Lyle, the decision was less about picking the “best” framework and more about setting the foundation for how the team would work and grow together.

Framework decisions shape culture. They signal what a team values, how approachable quality is for new contributors, and whether testing becomes a shared responsibility or a bottleneck.

Excitement, innovation, and the need for discipline

Lyle describes QA leadership today as genuinely exciting. The pace of innovation, especially with AI, has opened up new possibilities for how teams think about testing and quality engineering.

At the same time, strong fundamentals still matter.

From his perspective, leading QA requires balancing innovation with discipline. Skilled QA professionals remain essential to guide quality decisions, apply context, and ensure tools are used intentionally rather than for novelty. AI can accelerate workflows, but it cannot replace judgment.

The role of QA leadership is increasingly about knowing when to lean into new capabilities and when to slow down and ask harder questions.

What really keeps QA leaders up at night

For leaders like Lyle, the biggest concern is not adopting the next tool. It is ensuring the department has the right mix of skills, both technical and interpersonal, to succeed in the future. This matters at a leadership level because it directly affects sustainability.

Teams need more than expertise with tools. They need communication skills, critical thinking, and the ability to adapt as systems, products, and expectations evolve. Without those skills, even the most advanced tooling can become a liability rather than an advantage.

Fast adoption, thoughtful use

Lyle points to real world examples where new capabilities required careful leadership, not just enthusiasm. When new features such as cy.prompt were introduced, adoption needed to be fast but thoughtful. The challenge was ensuring teams understood not only how the feature worked, but when it should be used and when it should not.
As a leader, he felt responsible for helping the team avoid unnecessary complexity or misuse that could reduce effectiveness instead of improving it. Clear guidance, shared standards, and open conversations became just as important as documentation.

Slowing down to move forward

These experiences shaped how Lyle approaches leadership today. Pressure can push teams toward fast solutions, but rushed quality decisions often create more work later. He now places greater emphasis on evaluating broader impact and long term consequences, especially when introducing new tools or practices.
Slowing down is not resistance to progress. It is a way to protect teams from churn, burnout, and fragile systems.

A final reflection for QA and engineering leaders

If Lyle could leave other QA or engineering leaders with one reflection, it would be this:

Keep learning. The future is exciting, and new tools and skills are essential. Just do not lose sight of the core principles of quality that make those tools effective in the first place.

If you are looking for leadership content that keeps you and your team ahead of the curve, register for CypressConf 2026 and learn from industry leaders defining success in modern software development.

🚀 Enhancing Cypress Test Stability and Retry Capabilities

Laerte Neto — Tue, 13 Jan 2026 15:31:18 +0000

Introduction

The cypress-retry-after-run plugin brings a smart way to rerun only the tests that failed in a previous Cypress run, saving pipeline time, infrastructure resources, and frustration when dealing with flaky tests. It was designed mainly for real-world teams that run large suites in CI/CD and do not want to pay the price of re-executing the entire test set just because a handful of tests were unstable.

The problem this plugin solves

In modern QA pipelines, it is very common to have:

Large suites that take minutes (or hours) to run and consume a lot of CI resources.
Intermittent tests (flaky tests) that fail occasionally due to environment instability, networking, data issues, and so on.
A real need to isolate and rerun only what failed, instead of running everything again manually or rerun on demand, as the data can be corrupted at runtime.

Native Cypress retries will retry the test within the same execution, but that is not always what you want. In many pipelines, you first want to run the full suite, then do something (deploy fresh data, restart a service, clean up the environment), and only then trigger a new execution focused exclusively on the failures.

Core idea of `cypress-retry-after-run`

The plugin implements a two-step flow:

During the normal run, it listens to test execution and records failed tests into a .cypress-failures.json file at the project root.
Then you trigger a CLI command (cypress-retry) that reads this file, uses @cypress/grep under the hood, and starts a new Cypress run that executes only the tests that failed before.

In practice, the plugin turns “Run once, record failures, and rerun only what matters”.

Concrete benefits for CI/CD

For CI/CD pipelines, cypress-retry-after-run delivers very tangible advantages:

Time savings: instead of running the entire suite twice, the second run usually will be much smaller and focused only on the failed specs/cases.
Lower infrastructure cost: fewer runner minutes, fewer containers, less CPU and memory usage on shared environments.
More focused feedback: you quickly get a clean “retry run” that shows only the behavior of the failed tests, which helps distinguish real bugs from pure flakiness (either due to the tests or due to the environment, bad data, or other things), so it will make your debugging much faster, specially in larger suites as mentioned.

This pattern is especially useful for:

Pipelines that run multiple times a day.
Monorepos with dozens or hundreds of specs (which was my case, by the way).
Quality gates that only block merges if failures persist even after a dedicated retry run.

How the plugin works under the hood

The internal logic is simple but powerful:

Execution hook: the plugin plugs into Cypress via setupNodeEvents and listens to information about failed tests as the run progresses.
Persistence: at the end of the run, it writes a .cypress-failures.json file with identifiers of the tests/specs that failed.
Smart CLI: the cypress-retry command reads this file, builds the proper filters, and starts a new Cypress execution using @cypress/grep to run only the relevant tests.

Effectively, you get a selective replay of the failing tests, fully automated and integrated into your normal Cypress workflow.

Easy installation

Installation follows the standard pattern for modern Cypress plugins, with no extra friction.

With npm:
- npm install --save-dev cypress-retry-after-run @cypress/grep.
With yarn:
- yarn add -D cypress-retry-after-run @cypress/grep.

The only additional requirement is @cypress/grep, which the plugin uses to filter tests on the retry run, so it is installed alongside the plugin in a single command.

JavaScript and Typescript configuration

This plugin can be used in both JS and TS projects. Refer to the plugin's official npm link to get the full instructions on how to set it up and how to run it:

https://www.npmjs.com/package/cypress-retry-after-run

Pipeline and automation integration

cypress-retry-after-run fits naturally into any CI/CD pipeline design.

Step 1 – Main run:
- A standard job that runs the full suite (if you want) and generates .cypress-failures.json if there are failures.
Step 2 (Optional) – Do anything, like cleaning a database, or any operation in the environment you want, if necessary.
Step 3 – Automated retry:
- A second job/step that executes npm run retry (or an equivalent command you created) only if the failures file exists and/or if the previous job failed.

This design enables:

Conditional pipelines (retry only if there were actual failures).
Richer monitoring (separate dashboards for the full run and the retry run).
Smarter alerting (a test that still fails even after a dedicated retry can trigger a stronger alert or block a merge).

Why this plugin stands out

A few things make cypress-retry-after-run stand out in the Cypress ecosystem:

Built from real QA pain points: the “run everything, fix the environment, then rerun only failures” flow comes directly from production CI/CD needs.
Native integration with @cypress/grep: instead of reinventing filtering, it relies on a widely used community library, staying aligned with the Cypress ecosystem.
Minimal configuration: just a few lines in cypress.config and in the support file are enough to adopt it in both new and legacy projects.
Lightweight and focused: small package, no unnecessary dependencies, easy to drop into any repository without bloating your project.

For teams that already care deeply about automation quality and are tired of flakiness and wasted CI resources, cypress-retry-after-run is a strong ally to make pipelines more efficient, predictable, and truly professional.

You can check both links below with the plugin and a LinkedIn post with everything here, but summarized:

Triggering Cypress End-to-End Tests Manually on Different Browsers with GitHub Actions

Talking About Testing — Fri, 19 Dec 2025 19:29:32 +0000

A Practical Guide to Cross-Browser Testing

One of the most practical features of GitHub Actions is the ability to manually trigger workflows and pass parameters at runtime. This is especially useful for end-to-end (E2E) testing, where you may want to select which browser to run the tests against rather than hard-coding that choice.

In this post, I'll walk you through a GitHub Actions workflow written in YAML that allows you to manually trigger Cypress tests and select the target browser directly from the GitHub UI.

The Full Workflow

Here's the workflow I'll be explaining:

name: End-to-end tests 🧪
on:
  workflow_dispatch:
    inputs:
      browser:
        description: "Browser to run tests"
        type: choice
        required: true
        default: chrome
        options:
          - chrome
          - edge
          - electron
          - firefox
          - safari
jobs:
  cypress-run:
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Install WebKit system deps (Safari)
        if: ${{ github.event.inputs.browser == 'safari' }}
        run: npx playwright install-deps webkit

      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          command: npm run test:${{ github.event.inputs.browser }}

      - name: Upload screenshots (selected browser, on failure)
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: screenshots-${{ github.event.inputs.browser }}
          path: cypress/screenshots
          if-no-files-found: ignore

Naming the Workflow

name: End-to-end tests 🧪

This is the friendly name shown in the GitHub Actions UI. Adding an emoji is optional, but it makes workflows easier to scan—especially when you have many of them.

Manual Trigger with `workflow_dispatch`

on:
  workflow_dispatch:

The workflow_dispatch event enables manual execution of the workflow. This means:

The workflow won't run automatically on push or pull_request
A "Run workflow" button will appear in the Actions tab

This is ideal for:

Ad-hoc test runs
Debugging browser-specific issues
Running tests before a release

Defining Input Parameters

inputs:
  browser:
    description: "Browser to run tests"
    type: choice
    required: true
    default: chrome
    options:
      - chrome
      - edge
      - electron
      - firefox
      - safari

This is the heart of the workflow.

What's happening here?

browser is a required input
The user must select one value from a predefined list
The default option is chrome

On GitHub, this renders as a dropdown selector in the UI.

This prevents invalid values and makes the workflow safer and more user-friendly.

Defining the Job

jobs:
  cypress-run:
    runs-on: ubuntu-24.04

The workflow has a single job called cypress-run
It runs on the ubuntu-24.04 GitHub-hosted runner

Ubuntu runners are commonly used for Cypress because they're fast, stable, and well supported by the Cypress GitHub Action.

Step 1: Checking Out the Code

- name: Checkout
  uses: actions/checkout@v6

This step pulls your repository code into the runner so that:

Cypress tests
package.json
Configuration files

are available during execution.

This step is required in almost every CI workflow.

Step 2: Installing Safari (WebKit) Dependencies Conditionally

- name: Install WebKit system deps (Safari)
  if: ${{ github.event.inputs.browser == 'safari' }}
  run: npx playwright install-deps webkit

This is an excellent example of conditional execution in GitHub Actions.

Why is this needed?

Cypress runs Safari tests via WebKit
WebKit requires additional system dependencies on Linux
These dependencies are unnecessary for other browsers

What the condition does

The if expression ensures that this step:

Runs only when safari is selected
Is skipped for all other browsers

This keeps the workflow:

Faster
Cleaner
Easier to maintain

Notes:

It's worth mentioning that for Cypress to work with WebKit:

The experimentalWebKitSupport property has to be set to true in the cypress.config.js file
playwright-webkit has to be installed as a dev dependency (e.g., npm i playwright-webkit -D)

Pro tip: Make sure to version not only the package.json file, but also the package-lock.json.

Step 3: Running Cypress with the Selected Browser

- name: Cypress run
  uses: cypress-io/github-action@v6
  with:
    command: npm run test:${{ github.event.inputs.browser }}

This step uses the official Cypress GitHub Action image.

Key idea

The browser input is injected dynamically into the command:

npm run test:chrome
npm run test:firefox
npm run test:safari

This implies that your package.json contains scripts like:

{
  "scripts": {
    "test:chrome": "cypress run --browser chrome",
    "test:firefox": "cypress run --browser firefox",
    "test:safari": "cypress run --browser webkit"
  }
}

This pattern keeps:

The workflow generic
Browser-specific logic inside your project configuration

Step 4: Uploading Screenshots on Failure

- name: Upload screenshots (selected browser, on failure)
  if: failure()
  uses: actions/upload-artifact@v4
  with:
    name: screenshots-${{ github.event.inputs.browser }}
    path: cypress/screenshots
    if-no-files-found: ignore

This step runs only if the job fails.

What it does

Uploads Cypress screenshots as workflow artifacts
Names the artifact based on the selected browser
Avoids failing the workflow if no screenshots exist

Why this matters

When an E2E test fails:

Screenshots provide visual context
Browser-specific issues are easier to diagnose
Artifacts are preserved for later analysis

Final Thoughts

This workflow demonstrates a clean and scalable way to:

Manually trigger Cypress tests
Select the target browser at runtime
Handle browser-specific dependencies
Collect meaningful artifacts on failure

It's a powerful pattern for teams that care about cross-browser confidence without overloading their CI pipelines with unnecessary runs.

More than just automation, this approach puts control and observability back in the team's hands—exactly where quality belongs.

For the complete implementation, take a look at the cross-browser-testing-gha GitHub repository.

Would you like to learn E2E Testing with Cypress from scratch until your tests are running on GitHub Actions and integrated with the Cypress Cloud?

Consider subscribing to my course: "Cypress, from Zero to the Cloud."

How to validate tables, rows or any content of an Excel file using Cypress

Marcelo C. — Fri, 31 Oct 2025 11:43:24 +0000

At the company I work for, we already have many test cases to validate a key behavior of our SaaS, which through the user downloads a table as an Excel file of the information needed. But there was a need to validate some edge cases, in which we also needed to validate that the content corresponds to what the table showed.

This would mean that Cypress needs to deterministically validate rows, numbers, names and even colors inside the Excel file set by our user flows. After some research, we basically came upon two Node.js libs: @e965/xlsx and exceljs.

While @e965/xlsx is mostly used for data content validation, as in validating a JSON rows straight from the sheet - exceljs is more focused for style assertion, meaning assertions like “is A1 light-green?”. All right, so now we could split keeps tests readable and fast.

Configuring @e965/xlsx library

First, wire up the configuration in Cypress. Head off to Node with cy.task(). It’s the official way to run filesystem code from Cypress tests: register tasks in setupNodeEvents and they’ll return values back to your spec.

Remember to also import the package on the config file:

//cypress.config.ts

const xlsx = require('@e965/xlsx');
...
...
...
      on('task', {
        async readExcelByPattern(pattern: string, timeoutMs = 15000) {
          const re = new RegExp(pattern);
          const end = Date.now() + timeoutMs;

          while (Date.now() < end) {
            const files = fs.readdirSync(downloadsDir).filter(f => re.test(f) && !f.endsWith('.crdownload') && !f.endsWith('.tmp'));

            if (files.length) {
              const { fullPath } = files
                .map(f => {
                  const fullPath = path.join(downloadsDir, f);
                  return { fullPath, mtime: fs.statSync(fullPath).mtimeMs };
                })
                .sort((a, b) => b.mtime - a.mtime)[0];

              await sleep(200);

              const wb = xlsx.readFile(fullPath);
              const sheet = wb.Sheets[wb.SheetNames[0]];
              const data = xlsx.utils.sheet_to_json(sheet);
              return { fileName: path.basename(fullPath), data };
            }

            await sleep(300);
          }

          throw new Error(`File .xlsx taht matches /${pattern}/ not found on "${downloadsDir}" inside ${timeoutMs}ms`);
        },

You can see that readExcelByPattern is the task we should call to validate the content like rows, tables and any information inside the Excel file. You can then define it inside your test context and methods (or define it globally over commands.ts if you plan to use it in many tests), but for a single test it should look something like this:

//my-testing-context.ts

  @step('Read downloaded excel values')
  readExcelDownloadedFile(
    pathToFile: string = 'excel_export/bugs/',
    fixture: string,
    fileName: string
  ): ExportPrintableReportContext<TParent> {
    cy.fixture(pathToFile + fixture).then((expected: any[]) => {
      cy.task('readExcelByPattern', fileName).then(({ data }: { data: any[] }) => {
        expect(data.length, 'Table length').to.equal(expected.length);
        expected.forEach((expectedRow, i) => {
          const actualRow = data[i];
          Object.entries(expectedRow).forEach(([key, expectedValue]) => {
            const actualValue = actualRow[key] === undefined ? null : actualRow[key];
            expect(actualValue, `Row ${i} - Column "${key}"`).to.equal(expectedValue);
          });
        });
      });
    });
    return this;
  }

As you can see it's pretty straight forward, it calls for a JSON file inside 'fixtures/excel_export/bugs/' that already has the values you want to validate and should be equal to the Excel file and executes a forEach of the Table length, and each row, which already awaits for a value.

And this is how it would look inside a test:

import { testContext } from '@/my-testing-context'

const testingContext = new testContext();

describe('example of reading excel files', => ()
  it('case 1', () => {
    testingContext.readExcelDownloadedFile('excel_export/bugs/', tk, 'Excel.xlsx');
  });
});

Basically it checked 171 rows of the file content and succeeded in 40 seconds.

For the second part of this tutorial, I'll expand on how to validate Excel colors as well. Happy testing!

How to get most out of cy.prompt() - 6 tips and tricks for your new AI tool!

Marcelo C. — Thu, 09 Oct 2025 13:54:06 +0000

I know, I know, Cypress has just announced a game changing feature with cy.prompt() that is going to change the way we test - or at least approach how we think of it. You're going to use Natural Language all the way to test your new app? Read through my recommendations then!

As a Cypress Ambassador I was lucky enough to be using cy.prompt for the past weeks and here are a few tips to make your testing and usage go a bit smoothly.

1) Start your phrase with the action or assertion you want

Instead of giving it an instruction like:

When the page loads, check that the header is seen and then click on Create button

Would be better to:

Wait 8 seconds for the page to load
Assert that the header is visible
Click on create button

Now Cypress will translate your instructions more easily - a hardcoded wait, followed by an assertion, followed by a click.

2) Try to separate instructions

The previous step gave it away already! Cypress prompt works as any other LLM - give clear instructions of what you want to do and it'll have a better chance to execute it.

Do not mix assertions, with force clicks, with reloads in the same line of action! The prompt needs to go through, so in a way try to act as a prompt engineer and step by step you'll get there.

3) You can have up to 20 steps for each prompt you execute

20 is the limit, ok. But that doesn't mean that you need to have 20 steps each prompt. Also, the more steps you add, the prone it is to ask for clarifications or make mistakes.

Think of it as this: each plain English text line you introduce is an abstraction layer, right? Do want an over-complicated test, or a easy to read through, understandable (for non-developers specially) test?

Lesser is better in some cases!

4) Leave some tests in prompt in order to validate flaky behavior

Got a new feature? Want to avoid brittle in your E2E test? Want to check for any weird behavior here and there? Then cy.prompt is your way to go! You can always leave your tests in plain English to see if the BDD/TDD behavior stays the same.

Remember: it works in both local and CI - but it only supports Chrome or Chromium browsers (Edge/Electron). Any others are out (sorry Firefox!). Leave it a few days or weeks in your CI in prompt scenario and see what happens.

5) Portability first?

For me any test that is written in plain English has a natural advantage over each other. It doesn't need to be refactored into any other programming language. So if you already know that the application you're working now is starting to be ported into another modern framework, leave your tests in prompt format. Your devs will appreaciate!

6) It's always cached

Another advantage with cy.prompt is that once it runs, it will cache the steps in order to avoid LLM interaction. But if you change one line in your prompt - wait 15 seconds instead of 8, for example - it will execute all over again.

Remember this to focus on speed and reliability in your tests!

How Cypress will revolutionize the use of AI in testing with cy.prompt()

Marcelo C. — Thu, 09 Oct 2025 10:28:22 +0000

Cypress has become the go-to testing framework for SDETs and QA engineers to validate modern web apps. It’s fast, reliable, and backed by a mature ecosystem—both in software updates and excellent documentation. Add to that the vibrant community building powerful plugins and extensions, and it’s clear why Cypress dominates the testing landscape.

Cypress is taking a bold step into AI-powered testing with the upcoming cy.prompt(). Unlike typical AI integrations that act as external copilots or rely on general-purpose MCP-style assistants, cy.prompt() adds the intent (what we want) built directly into the testing workflow.

This means no context switching, no juggling between an IDE plugin and your test runner. Instead, Cypress allows you to describe your intent in plain English, and the AI automatically generates selectors, actions, and assertions right inside your test.

It’s a shift from writing tests line by line to guiding your tests conversationally. Think less about cy.get() or cy.click() and more about telling Cypress what you want verified, letting the framework translate that into executable code.

Here’s a video demonstration of cy.prompt() in action:

This is the code that I used in the validation:

And here is what the prompt suggests of code locators right after is executed:

Also, you can leave the prompt as it is and push to your CI/CD pipeline:

With cy.prompt(), Cypress is no longer “just” a testing framework—it’s stepping into the AI-assisted development era. For SDETs and QA engineers, this means faster authoring, smarter locator handling, and easier onboarding for teams.

The possibilities of cy.prompt()

Cy.prompt focus on the intent: what we want, not how do do it. It's a great tool for non-developers, or anyone who doesn’t want to dive deep into app implementation.
Imagine writing the BDD (Behavior Driven Development) acceptance criteria directly into the test. You'll have the best of both worlds here, BDD criteria that is understood by all stakeholders (Project Managers, Product Owners), and the code being executed in the background.
TDD (Test-Driven-Development) is also covered for the developers. Imagine developing a feature until is ready and, step by step (word by word, line by line) it start to pass. Until is ready for deployment.
Portability is here: Need to refactor your project? Move from one programming language to another? Don't need to change a thing in your tests written in plain English, they can be easily shared, exported, or integrated across different systems.
Also, another great benefit here are the self-healing tests, they’re more resilient to changes in the DOM or selectors. This feature could fundamentally change how we approach automation.

The future of QA is not just code—it’s collaboration between AI and testers.

What are your thoughts?

Share, comment or connect with me directly in LinkedIn!

Six Technical Sessions That Will Change How You Think About Testing

Ronald Williams — Tue, 02 Sep 2025 15:04:00 +0000

Tired of expensive learning materials that take weeks to complete but teach you nothing you can't Google? Fed up with content that assumes you're still figuring out basic assertions when you're managing complex test architectures?

CypressConf 2025 workshops solve the learning problem that plagues experienced developers: finding advanced, practical content that matches your skill level and specific to your setup without the cost barriers or time wasting. Over two exclusive workshop days (October 23–24), global industry practitioners will teach you competitive skills you can implement Monday morning. These workshops were designed based on years of attendee feedback from our global community, focusing on the real problems you've told us you're solving right now.

Slack 'n' Roll: CI/CD Pipelines with GHA
Led by: Tanya Sahni, Software Developer in Test at Fashion Cloud

Your CI/CD pipeline should work for you, not against you. Tanya will show how to integrate Cypress into GitHub Actions so your tests run automatically and notify your team intelligently. This intermediate to advanced workshop assumes you're already comfortable with CI/CD concepts and want to build pipelines whose scale reliably", eliminating the manual check dance that wastes hours every sprint and positioning you as the developer who builds systems that move as fast as your code.

Advocate for Quality Within Your Company
Led by: Péter Földházi, Quality Architect at EPAM Systems

Quality isn't just a QA responsibility. It's an organizational capability. This senior-level workshop teaches experienced QA professionals how to become effective advocates for quality across engineering teams. You'll learn to speak business language while maintaining technical standards, turning quality from a cost center into a competitive advantage and transforming how your organization views testing so you lead change instead of reacting to it.

Operationalizing Quality with Data That Matters
Presented by: Dan Johansen, Senior Product Manager at Cypress.io

Raw testing data is noise. Actionable insights are signal. Dan demonstrates how to turn test results into meaningful metrics that improve release decisions. This intermediate to senior workshop teaches which data points actually matter and how to present them in ways that influence engineering strategy, enabling you to make data-driven quality decisions that leadership understands and supports.

Data Driven Testing with Cypress
Delivered by: Marko Kolasinac, CEO at Assert QA, and Dejan Živković, QA Automation Engineer at Assert QA

Hardcoded test data creates maintenance nightmares. This intermediate workshop shows how to design resilient, data-powered testing strategies that don't interfere with production systems. Marko and Dejan assume you understand testing fundamentals and focus on building migration approaches that scale without the complexity overhead that kills productivity.

Simplifying Cypress Testing
Led by: Walmyr Filho, Instructor and Founder at Talking About Testing

Writing Cypress tests isn't just writing JavaScript. It requires different thinking. Whether you're new to Cypress or have been using it for years, Walmyr shares practical techniques for writing maintainable tests that grow with your product complexity. You'll learn patterns that prevent technical debt before it accumulates, building tests that remain valuable as your codebase evolves rather than becoming liabilities.

Authentication Workflows with Cypress & Mailosaur
Led by: Filip Hric, Developer Educator at filiphric.com

Authentication testing is notoriously brittle. Filip walks through testing authentication flows so your login and access systems remain reliable across environments. This intermediate to advanced workshop handles real-world scenarios including email verification, multi-factor authentication, and role-based access, helping you secure reliable user experiences without compromising test stability.

What Makes These Workshops Different

These sessions were built from years of global community feedback. Developers told us they needed advanced content that respects their experience level, practical sessions they could apply immediately, and learning opportunities that didn't require expensive course subscriptions or weeks of commitment.

Each workshop delivers concentrated expertise from practitioners who've built testing systems at scale. No generic tutorials. No basic concepts you already know. Just advanced techniques that solve real problems you're encountering in production environments.

Workshop seats are intentionally limited and fill fast. You must be registered for CypressConf 2025 to access workshops, and early registrants get first access before standby lists open.

More workshops are coming soon.

Cypress v15: A Better User Experience

Talking About Testing — Tue, 19 Aug 2025 23:45:47 +0000

Streamlined Features and Improvements for Modern Testing

Cypress v15 is just around the corner, and one of the exciting changes is an improved user experience in the command logs of the test runner. If you’ve spent time debugging tests in v14, you’ll immediately notice how v15 makes test execution logs easier to scan, parse, and act upon.

In this post, we’ll walk through the key UX improvements.

At the end of this post, screenshots will illustrate the differences between v14 and v15.

Hierarchical Grouping

In v15, the test log is segmented into clear sections with borders to distinguish between: SESSIONS, BEFORE EACH, and TEST BODY.
In v14, although SESSIONS, BEFORE EACH, and TEST BODY also appear, there's no border to differentiate and isolate them better.

Cleaner Visual Density

The v15 layout introduces tighter grouping and spacing, so related blocks are easier to scan. The result is less eye travel compared to v14’s list.

Final Thoughts

Cypress v15 isn’t just a version bump—it’s a thoughtful step forward in how developers and testers interact with their test runner. By rethinking the command log experience with hierarchical grouping and cleaner visual density, Cypress reduces cognitive load and makes debugging more intuitive.

If you’ve ever found yourself lost in the flat logs of v14, v15 will feel like a breath of fresh air. These changes may seem subtle, but they directly improve day-to-day productivity and test clarity. And when it comes to testing, minor UX improvements often translate into big wins for speed, focus, and confidence.

As Cypress continues to evolve, v15 is a reminder that great tooling isn’t just about raw features—it’s about delivering a user experience that helps teams ship quality software faster.

Illustrations comparing Cypress versions 14 and 15

v14 session collapsed

v15 session collapsed

v14 session expanded

v15 session expanded

Would you like to learn more about web testing with Cypress?
Check out the "Cypress, from Zero to the Cloud" course from the Talking About Testing online school, and happy testing!

XLSX File Uploads in Cypress

Paul Astorga — Tue, 29 Jul 2025 19:01:25 +0000

XLSX File Uploads in Cypress: A Comprehensive Guide

As QA automation engineers, we often rely on fixtures to manage test data in Cypress. However, there are times when fixtures aren't enough, especially when dealing with file uploads. In my experience, interacting with XLSX files can present unique challenges, particularly when the application requires dynamic, rather than static, file uploads. While resources exist online, they often provide fragmented information, making it difficult to piece together a complete solution.

This blog post aims to consolidate that scattered knowledge into a single, comprehensive guide. If you're looking to add robust XLSX file upload testing to your Cypress test suite, this post will provide you with a step-by-step approach, complete with code examples and explanations.

The Challenge: Dynamic XLSX File Generation

While Cypress provides the cy.writeFile command for file creation, it falls short when it comes to generating functional XLSX files. Attempting to create an XLSX file using cy.writeFile results in a file that either fails to open or is recognized as an unsupported/corrupted format. This is because the command doesn't write the file in the correct binary format required for XLSX files.

The Solution: Leveraging Node.js and the XLSX Library

To overcome this limitation, we can harness the power of Node.js and the xlsx library. This library allows us to create XLSX files programmatically in the correct format.

Step 1: Installing the XLSX Package

First, let's install the xlsx package using npm:

npm install xlsx

Step 2: Configuring Cypress to Use the XLSX Library

Next, we need to configure Cypress to use the xlsx library by adding a task to our cypress.config.js (or plugins/index.js) file. This task will handle the XLSX file creation process.

// cypress.config.js (or plugins/index.js)
const xlsx = require('xlsx');
module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      on('task', {
        writeXLSX({ filePath, data, sheetName = 'Sheet1' }) {
          const ws = xlsx.utils.json_to_sheet(data);
          const wb = xlsx.utils.book_new();
          xlsx.utils.book_append_sheet(wb, ws, sheetName);
          xlsx.writeFile(wb, filePath);
          return null; // Tasks must return a value or a Promise
        },
      });
      return config;
    },
  },
};

Explanation:

We require the xlsx library.
We define a task called writeXLSX that accepts the file path, data, and sheet name as arguments.
Inside the task, we use the xlsx library to convert the data (in JSON format) to a worksheet, create a workbook, append the worksheet to the workbook, and then write the workbook to the specified file path.

Step 3: Creating a Cypress Test to Generate and Upload the XLSX File

Now that we have configured Cypress to use the xlsx library, we can create a test to generate and upload the XLSX file.

describe('XLSX Creation and Upload Test', () => {
  it('should write data to an XLSX file and upload it', () => {
    const testData = [
      { Name: 'John Doe', Age: 30, City: 'New York' },
      { Name: 'Jane Smith', Age: 25, City: 'London' },
    ];
    const filePath = 'cypress/fixtures/output.xlsx';
    cy.task('writeXLSX', { filePath, data: testData }).then(() => {
      cy.log('XLSX file written successfully!');
      cy.get('[type="file"]').selectFile(filePath, { force: true });
    });
  });
});

Explanation:

We define an array of objects (testData) representing the data we want to write to the XLSX file. Each object represents a row in the spreadsheet.
We define the file path where we want to save the XLSX file.
We use the cy.task command to call the writeXLSX task we defined in the cypress.config.js file.
Once the task completes, we use the cy.get command to locate the file input element on the page (identified by the type="file" attribute) and then use the cy.selectFile command to select the generated XLSX file. The { force: true } option is used to bypass any visibility checks.

Understanding cy.selectFile

The cy.selectFile command is a powerful tool for simulating file uploads in Cypress. It allows us to select a file from our system and upload it to the HTML input element, effectively simulating the user dragging the file into the browser. This eliminates the need to interact with the "Browse" button and the file search modal, making our tests more robust and easier to maintain.

Additional Resources:

Cypress writeFile Command: https://docs.cypress.io/api/commands/writefile
Cypress selectFile Command: https://docs.cypress.io/api/commands/selectfile
XLSX Library: https://www.npmjs.com/package/xlsx

Conclusion:

This guide provides a clear and concise approach to handling XLSX file uploads in Cypress. By combining the power of Node.js, the xlsx library, and Cypress commands like cy.task and cy.selectFile, you can create robust and reliable tests that accurately simulate user interactions with file uploads. I hope this guide helps you streamline your Cypress testing process and confidently tackle XLSX file uploads in your applications.

Happy testing!

From 1-Hour Nightmares to 7-Minute Dreams: Our Cypress Cloud Journey

S Chathuranga Jayasinghe — Wed, 23 Jul 2025 06:00:46 +0000

How we transformed our testing workflow at TrackMan and why Cypress Cloud became our testing superhero

Picture this: It’s 3 PM on a Friday, you’ve just pushed what you think is a small fix, and now you’re staring at your terminal watching Cypress tests crawl by at a snail’s pace. One test… two tests… still going… Your weekend plans are slowly evaporating as you realize you’ve got another 45 minutes to wait before you know if your code actually works.

Note: Don’t deploy on Fridays!

Sound familiar? That was our reality at TrackMan not too long ago.

The Dark Ages: When Testing Felt Like Punishment

Let me paint you a picture of how things used to be. Our Cypress test suite had grown into this massive beast that took nearly an hour to complete. An entire hour! We were running everything sequentially, watching tests execute one by one like we were back in the dial-up internet era.

The worst part? When something broke (and trust me, things broke), debugging was an absolute nightmare. You’d get a cryptic failure message, maybe a screenshot if you were lucky, and then you’d have to play detective, trying to figure out what went wrong. It was like trying to solve a murder mystery with half the clues missing.

We were using Cypress Custom Commands, which seemed like a good idea at the time, but as our test suite grew, maintaining and understanding the flow became increasingly difficult. The whole experience was just… painful.

The Lightbulb Moment: Enter Cypress Cloud

After months of frustration and countless hours lost to slow test runs, we finally decided enough was enough. We’d heard whispers about Cypress Cloud, but like many teams, we were hesitant to make the switch. “Another tool to learn? Another service to manage?” But honestly, we were desperate.

Best decision we ever made!

The Transformation: From Hours to Minutes

Here’s where things get exciting. Remember that nearly 1-hour test suite I mentioned? After moving to Cypress Cloud and implementing parallelization, it now runs in just 7 minutes.

Let me repeat that: 7 minutes.

I’m not exaggerating. We went from grabbing coffee, checking emails, and sometimes even taking walks during test runs to barely having time to refill our water bottles.

What Made the Magic Happen

Smart Test Orchestration: The Brain Behind the Operation

Cypress Cloud’s Smart Test Orchestration is like having a really smart project manager for your tests. Instead of running tests in some random order, it analyzes your test history and intelligently distributes them across multiple machines. Tests that typically take longer get started first, while quicker tests fill in the gaps. It’s beautiful to watch in action.

Parallelization: Divide and Conquer

We’re currently running with parallelization enabled, and it’s a game-changer. Instead of one machine plodding through all our tests, we have multiple machines working simultaneously. Think of it like having multiple checkout lanes at a grocery store instead of making everyone wait in one long line.

With around 44,000 test results per month (yes, we test a lot!), this parallel execution saves us countless hours every single month.

Page Object Model: A Much-Needed Architectural Shift

While we were at it, we also moved from Cypress Custom Commands to the Page Object Model (POM). This wasn’t directly related to Cypress Cloud, but it complemented our new setup perfectly.

Custom Commands felt scattered and hard to maintain as our test suite grew. With POM, everything is organized, reusable, and much easier to understand. Each page has its own class with methods that represent the actions you can perform on that page. It’s clean, it’s logical, and it makes onboarding new team members so much smoother.

Test Replay: The Debugging Superhero We Never Knew We Needed

Now, let’s talk about the feature that has truly saved our sanity: Test Replay.

Remember those debugging nightmares I mentioned earlier? They’re basically extinct now. When a test fails, Test Replay captures everything. And I mean everything. Every click, every hover, every network request, every DOM change it’s all there, recorded and ready to be analyzed.

You can literally watch your test execution step by step, like you’re sitting right next to the browser as it runs. You can see exactly where things went wrong, what the page looked like at that moment, and what data was flowing through your application.

Test Analytics: Your Personal Test Performance Detective

But Test Replay is just the tip of the iceberg. Cypress Cloud’s Test Analytics dashboard has become our command-center for test optimization. Here’s where things get really interesting.

The Slowest Tests view is pure gold. It shows you exactly which tests are dragging down your entire suite. We discovered that three specific tests were accounting for nearly 40% of our total execution time! Once we optimized those, we shaved off another couple of minutes from our already improved 7-minute runtime.

The Failure Reasons analytics helped us identify patterns we never would have caught manually. Turns out, we had several tests failing due to timing issues that only happened when running in parallel. The dashboard made it crystal clear which tests were problematic and why.

Flaky Test Detection: No More “It Works on My Machine”

Here’s something that used to drive us absolutely crazy: flaky tests. You know, those tests that pass 90% of the time and then randomly fail, usually right before an important release.

Cypress Cloud’s Flaky Test Detection is like having a data scientist dedicated to analyzing your test stability. It tracks your test results over time and flags tests that show inconsistent behavior. We can now see exactly how flaky a test is (like “passes 85% of the time”) and prioritize which ones to fix first.

The best part? It gives you insights into what might be causing the flakiness. Network timeouts? Element loading issues? Race conditions? The data helps you pinpoint the root cause instead of just crossing your fingers and hoping for the best.

Cypress Cloud AI: The Future is Here

And then there’s the newest addition that honestly feels like magic: Cypress Cloud AI. When a test fails, it doesn’t just show you what happened it analyzes the failure and suggests what might have gone wrong.

I’m talking about actual AI-powered suggestions like “This test appears to be failing due to a network timeout. Consider increasing the timeout or mocking this network request.” It’s like having a senior QA engineer looking over your shoulder, except this one never gets tired or takes coffee breaks.

The level of detail you get across all these features is incredible. Network timings, console logs, screenshots at every step it’s like having X-ray vision for your tests, but with a smart assistant helping you interpret what you’re seeing.

The Real-World Impact: Beyond Just Speed

Sure, going from 1 hour to 7 minutes is impressive, but the real benefits go much deeper:

Developer Happiness: Our team actually looks forward to running tests now. No more dreading that pre-deployment test run.

Faster Feedback Loops: We can iterate much quicker. Push a fix, wait 7 minutes, know if it works. The faster feedback makes us more confident and more productive.

Better Test Coverage: When tests run quickly, you’re more likely to write more of them. We’ve actually expanded our test coverage because the pain of long execution times is gone.

Easier Onboarding: New team members can understand our test failures quickly thanks to Test Replay. No more spending hours explaining “what probably went wrong.”

Predictable Releases: With reliable, fast tests and amazing debugging tools, our releases became much more predictable and less stressful.

The Numbers Don’t Lie

Let me put this in perspective with some real numbers:

Test execution time: From ~60 minutes to 7 minutes (88% reduction)
Monthly test results: 44,000+ tests handled smoothly
Debugging time: Reduced by approximately 70% thanks to Test Replay
Developer productivity: Immeasurably better (seriously, the mood in our standups improved!)

What We Learned Along the Way

It’s Not Just About the Tools

While Cypress Cloud provided the technical foundation for our improvement, we learned that success also required some process changes:

Embrace parallelization thinking: We had to restructure some tests that were inadvertently dependent on each other.
Invest in good test data management: With parallel execution, you need to be more careful about test data isolation.
Monitor and optimize continuously: The analytics provided by Cypress Cloud help us continuously improve our test suite.

The ROI is Real

Yes, Cypress Cloud is a paid service, but the time savings alone justify the cost. When you factor in developer productivity, faster release cycles, and reduced debugging time, it’s honestly a no-brainer.

Looking Forward

Moving to Cypress Cloud wasn’t just a technical upgrade — it was a complete transformation of how we approach testing. We went from viewing tests as a necessary evil to treating them as a competitive advantage.

If you’re sitting there reading this while waiting for your own slow test suite to finish, or if you’re tired of spending hours debugging mysterious test failures, I can’t recommend Cypress Cloud enough. The combination of Smart Test Orchestration, parallelization, and Test Replay creates a testing experience that’s not just faster, but genuinely enjoyable.

Trust me, your experience will thank me!

Have you made the switch to Cypress Cloud, or are you still on the fence? I’d love to hear about your testing experiences in the comments below. And if you decide to give Cypress Cloud a try, let me know how it goes, I’m always excited to hear about teams escaping the slow-test nightmare!

Forem: Cypress

How I stopped declaring login in each of my 5k tests

Cypress in the Age of AI Agents: Orchestration, Trust, and the Tests That Run Themselves

The Shift Nobody Talks About

Autonomy vs. Augmentation: The Framework That Matters

What Actually Happens When AI Writes Your Cypress Tests

The Architecture Cypress Teams Actually Need

Layer 1: AI Generates, Humans Gate

Layer 2: The Trust Boundary in CI

Layer 3: The Accountability Layer

Layer 4: Docker as the Trust Container

The Uncomfortable Question

What I'd Do This Week

The Bottom Line

Leading Quality Through Change: Balancing Speed, AI, and the Fundamentals That Matter

🚀 Enhancing Cypress Test Stability and Retry Capabilities

Introduction

The problem this plugin solves

Core idea of cypress-retry-after-run

Concrete benefits for CI/CD

How the plugin works under the hood

Easy installation

JavaScript and Typescript configuration

Pipeline and automation integration

Why this plugin stands out

Triggering Cypress End-to-End Tests Manually on Different Browsers with GitHub Actions

A Practical Guide to Cross-Browser Testing

The Full Workflow

Naming the Workflow

Manual Trigger with workflow_dispatch

Defining Input Parameters

What's happening here?

Defining the Job

Step 1: Checking Out the Code

Step 2: Installing Safari (WebKit) Dependencies Conditionally

Why is this needed?

What the condition does

Step 3: Running Cypress with the Selected Browser

Key idea

Step 4: Uploading Screenshots on Failure

What it does

Why this matters

Final Thoughts

How to validate tables, rows or any content of an Excel file using Cypress

How to get most out of cy.prompt() - 6 tips and tricks for your new AI tool!

How Cypress will revolutionize the use of AI in testing with cy.prompt()

Six Technical Sessions That Will Change How You Think About Testing

Cypress v15: A Better User Experience

Streamlined Features and Improvements for Modern Testing

Hierarchical Grouping

Cleaner Visual Density

Final Thoughts

Illustrations comparing Cypress versions 14 and 15

XLSX File Uploads in Cypress

From 1-Hour Nightmares to 7-Minute Dreams: Our Cypress Cloud Journey

The Dark Ages: When Testing Felt Like Punishment

The Lightbulb Moment: Enter Cypress Cloud

The Transformation: From Hours to Minutes

What Made the Magic Happen

Smart Test Orchestration: The Brain Behind the Operation

Parallelization: Divide and Conquer

Page Object Model: A Much-Needed Architectural Shift

Test Replay: The Debugging Superhero We Never Knew We Needed

Test Analytics: Your Personal Test Performance Detective

Flaky Test Detection: No More “It Works on My Machine”

Cypress Cloud AI: The Future is Here

The Real-World Impact: Beyond Just Speed

The Numbers Don’t Lie

What We Learned Along the Way

It’s Not Just About the Tools

The ROI is Real

Looking Forward

Core idea of `cypress-retry-after-run`

Manual Trigger with `workflow_dispatch`