Forem: Martin Chudomel

The Cypress Variable Trap: When if Runs Too Soon in Your Tests

Martin Chudomel — Thu, 27 Nov 2025 12:45:53 +0000

Cypress tests look synchronous, feel synchronous, but absolutely aren’t synchronous.

One of the most common pitfalls I see (and experienced myself) is mixing plain JS variables with Cypress’ command queue, especially when values come from async sources like APIs.

Scenario

Let’s walk through a simple scenario that breaks more often than not:

In before() hook, you fetch some value (e.g., from an API).
You assign it to a variable like this:

let featureEnabled = false
before(() => {
  cy.request('/api/features').then(response => {
    featureEnabled = response.body.enabled
  })
})

3. Then, in your test, you try to run logic based on that value:

it('does something when feature flag is enabled', () => {
  if (featureEnabled) {
    // test one thing
  } else {
    // test something else
  }
})

The Catch

This if (featureEnabled) block is a normal synchronous JavaScript condition.

But the value is set inside a Cypress command cy.request().then(), which runs later — via Cypress’ internal command queue.

So what often happens is:

The if condition evaluates before the API call has actually resolved, meaning the variable still holds the initial value.

Even though the code looks like it should work from top to bottom.

The reliable fix: Keep it in Cypress’ world

The key lesson:

Never use plain variables in test conditions if they depend on async Cypress commands.

What works every time is handing the value over to Cypress using cy.wrap() + alias:

before(() => {
  cy.request('/api/features')
    .its('body.enabled')
    .then(value => {
      cy.wrap(value).as('featureEnabled')
    })
})

Then in the test:

it('does something based on API feature flag', () => {
  cy.get('@featureEnabled').then(featureEnabled => {
    if (featureEnabled) {
      // test one thing
    } else {
      // test another
    }
  })
})

Now the if statement is safely nested inside a Cypress–managed async callback, and it always runs with the correct resolved value.

No race conditions. No false positives. No flaky tests.

Side notes

cy.wrap().as() does not magically make the variable reactive, it just stores it safely as a test alias.
.then() is not just syntax, it’s essential: it keeps your logic sequential within Cypress’ execution model.

This same trap occurs with cy.wait(), cy.intercept(), or anything else that resolves asynchronously.

Rule of thumb

If a variable’s value comes from any cy.* command, don’t evaluate it outside Cypress’ chain — alias it and consume it via cy.get().then().

Summary

Cypress’ execution model is one of its superpowers, but also the source of many “why did that run too early?” bugs.

Once you stop fighting it and start embracing aliases with cy.wrap() and cy.get().then(), your test suite becomes:

✔ deterministic
✔ more readable
✔ and dramatically less flaky

Integrating Cypress with Jenkins API for Automated Test Preparation

Martin Chudomel — Sun, 16 Mar 2025 16:49:02 +0000

When performing automated tests in Cypress (or any automation tool), you often need to prepare data or bring the application to a certain state before execution. This can involve seeding a database, generating test data, or performing backend tasks.

A common challenge in test automation is executing backend tasks before running tests. Traditionally, these tasks were triggered manually, preventing full test automation. However, integrating Jenkins API with Cypress allows us to programmatically launch Jenkins jobs, making the process seamless and fully automated.

Automating Pre-Test Jobs with Jenkins API

To incorporate Jenkins jobs into Cypress, we use the Jenkins API to start a job and wait for its completion. Let's define some custom Cypress commands to handle this.

Starting a Jenkins Job

We begin by defining a general function to start a Jenkins job:

const JENKINS_URL = '{your_jenkins_url}';
const JOB_NAME = 'Console script runner (dev-beta)'; // Define your job
const API_TOKEN = '{your_jenkins_api_token}';

function startJenkinsJob(project, script, wait) {
    cy.task('log', `Starting Jenkins job: ${script}`);
    const url = `${JENKINS_URL}/job/${JOB_NAME}/buildWithParameters?token=${API_TOKEN}&PROJECT=${project}&ENVIRONMENT=beta&CONSOLE_SCRIPT=${script}`;

    cy.request({
        method: 'GET',
        url: url,
        failOnStatusCode: false,
    }).then((response) => {
        if (wait) {
            const locationParts = response.headers.location.split('/');
            const queueId = locationParts.slice(-2, -1)[0];
            cy.waitForBuildNumber(queueId);
        }
    });
}

This function sends a request to Jenkins to start a job and retrieves a queue ID. Since jobs are queued before execution, we need to monitor the queue status. The actual job parameters (in this case project and environment) may differ based on your Jenkins configuration.

Waiting for jobs in queue

Next, we create a Cypress command to check the queue status:

Cypress.Commands.add('waitForBuildNumber', (queueId) => {
    cy.getQueueItemStatus(queueId).then((res) => {
        if (res.body.executable) {
            const buildNumber = res.body.executable.number;
            cy.task('log', `Job started with Build Number: ${buildNumber}`);
            cy.waitForJobCompletion(buildNumber);
        } else {
            cy.wait(3000); // Retry after 3 seconds
            cy.waitForBuildNumber(queueId);
        }
    });
});

This command checks if the job has moved out of the queue and received a build number. If not, it retries after a short delay.

Monitoring Job Completion

Once a job is assigned a build number, we can track its execution status:

Cypress.Commands.add('waitForJobCompletion', (buildNumber) => {
    cy.request({
        method: 'GET',
        url: `${JENKINS_URL}/job/${encodeURIComponent(JOB_NAME)}/${buildNumber}/api/json`,
        jenkinsAuth,
        failOnStatusCode: false,
    }).then((res) => {
        const result = res.body.result;
        if (result) {
            cy.task('log', `Job completed with status: ${result}`);
        } else {
            cy.wait(3000); // Retry after 3 seconds
            cy.waitForJobCompletion(buildNumber);
        }
    });
});

This command periodically checks whether the job has completed and logs its status.

Checking Queue Item Status

To get the queue item status, we define another Cypress command:

Cypress.Commands.add('getQueueItemStatus', (queueId) => {
    return cy.request({
        method: 'GET',
        url: `${JENKINS_URL}/queue/item/${queueId}/api/json`,
        jenkinsAuth,
        failOnStatusCode: false,
    });
});

Implementing Specific Jenkins Commands

With these general functions in place, we can define specific commands. For example, to clear a cache before running tests:

Cypress.Commands.add('clearCache', (country, wait) => {
    return startJenkinsJob('my_project', 'cache/flush-all country=' + country, wait);
});

Using Jenkins Jobs in Cypress Tests

Now, let's implement our cache-clearing command in a test:

describe('Test with cleared cache', () => {
    before(() => {
        const countryId = Cypress.env().countryId;
        cy.task('log', 'Clearing cache on ' + countryId);
        cy.clearCache(countryId, true);
    });

    it('Your test...', () => {
        // Your test code
    });
});

Expanding Possibilities for Automated Testing

Integrating Cypress with Jenkins API opens up many new opportunities:

Automatically setting up test environments.
Running backend processes before tests.
Ensuring data consistency before executing test cases.

With this approach, we eliminate the need for manual job execution, making our test automation more robust and reliable.

What other pre-test tasks would you automate with this method? Let’s discuss in the comments!

How to Conditionally Skip Tests in Cypress the Right Way

Martin Chudomel — Sun, 02 Feb 2025 21:23:03 +0000

When writing end-to-end tests in Cypress, you may encounter scenarios where you need to conditionally skip certain tests. Maybe you want to disable tests based on an environment variable, a feature flag, or a configuration setting. While it seems straightforward, there’s a common pitfall when trying to set the condition inside a before hook.

In this post, I’ll explain the problem and provide multiple ways to correctly handle conditional test execution in Cypress.

The Common Pitfall

A naive approach to skipping a test might look like this:

if (condition) {
    it('should run this test', () => {
        // test code
    });
}

This works fine if the condition is static. However, if the condition is determined inside a before hook, this approach fails because Cypress won’t even execute the before hook unless there’s at least one test to run.

The Fix: Place the Condition Inside the Test Block

Instead of skipping the test definition, move the condition check inside the it block:

it('should run this test only if condition is met', () => {
    if (!condition) {
        return;
    }

    // test code here
});

This ensures that the before hook runs, sets up the condition, and only then determines whether to run the test.

Alternative Approaches to Skipping Tests

1. Using `Cypress.env()` for Configuration-Based Skipping

If your condition is based on an environment variable, you can check it before defining tests:

if (Cypress.env('SKIP_TESTS')) {
    return;
}

it('should run only if SKIP_TESTS is false', () => {
    // test code
});

This is useful when you need to control test execution via external configurations.

2. Using `this.skip()` in a `beforeEach` Hook

If you need to dynamically determine whether to skip a test inside a beforeEach hook, use this.skip(), which is built into Mocha (Cypress’s underlying test framework):

beforeEach(function () {
    if (Cypress.env('SKIP_TESTS')) {
        this.skip();
    }
});

it('should be skipped when condition is met', () => {
    // test code
});

This approach is useful when multiple tests in a suite should be skipped dynamically.

3. Skipping Entire Suites Conditionally

If you want to conditionally skip an entire test suite (describe block), you can use:

(Cypress.env('RUN_TESTS') ? describe : describe.skip)('Conditional Test Suite', () => {
    it('test 1', () => {
        // test code
    });

    it('test 2', () => {
        // test code
    });
});

This method keeps the suite clean by completely excluding tests if RUN_TESTS is false or undefined.

Conclusion

Skipping tests conditionally in Cypress is essential for handling feature flags, environment differences, and flaky tests. However, you need to be careful about where and how you apply conditions, especially when dealing with before hooks.

To recap:

Move conditions inside the it block to avoid skipping before hooks.
Use this.skip() in beforeEach for dynamic skipping.
Skip entire test suites using describe.skip.
Leverage Cypress.env() for environment-based skipping.

By using the right approach, you can make your Cypress test suite more flexible and maintainable.

Efficient Cypress API Testing with Custom Commands

Martin Chudomel — Sun, 19 Jan 2025 20:55:13 +0000

When working on projects that involve extensive API testing, managing API requests in your Cypress tests can quickly become overwhelming. Writing repetitive cy.request() calls directly in test files not only makes them cluttered but also difficult to maintain. To address this, I’ve adopted a structured approach to organize and simplify API requests using custom commands in Cypress. Here, I’ll walk you through my solution step by step, which you can implement to streamline your API tests.

Step 1: A General Function for All Requests

The first step is to create a generic function to handle any type of API request. This function accepts parameters such as the HTTP method, URL, query parameters, request body, bearer token, and device headers. Here’s the implementation:

function callRequest(method, url, params, body, bearer, device) {
    var headers = {
        uuid: Cypress.uuid // Unique identifier for tracking requests
    }
    if (bearer) {
        headers.authentication = 'Bearer ' + bearer;
    }
    if (device) {
        headers['Origin-Type'] = device;
    }
    return cy.request({
        method: method,
        url: url,
        qs: params,
        body: body,
        headers: headers,
        failOnStatusCode: false,
    }).then((response) => {
        if (response.status === 500) {
            cy.task('log', `[\${new Date().toISOString()}] Request URL: \${url}, Parameters: \${JSON.stringify(params)}, Response: \${JSON.stringify(response.body)}`);
        }
        return cy.wrap(response);
    });
}

This function is a flexible foundation for all types of requests and ensures consistent handling of headers, query parameters, and error logging.

Step 2: Specific Functions for HTTP Methods

Since different HTTP methods often require varying parameters (e.g., GET typically doesn’t need a request body), I created separate functions for each method. For example:

function getRequest(url, params = { countryId: Cypress.env().countryId }, bearer) {
    return callRequest('GET', url, params, undefined, bearer);
}

function postRequest(url, params = { countryId: Cypress.env().countryId }, body, bearer) {
    return callRequest('POST', url, params, body, bearer);
}

This abstraction makes the code cleaner and avoids repeatedly specifying HTTP method details in every API call.

Step 3: Custom Cypress Commands

To further simplify API usage in tests, I created custom Cypress commands. Each command defines the specific endpoint URL and invokes the appropriate HTTP method function. Here are a couple of examples:

Cypress.Commands.add('getTranslation', (params) => {
    const reqUrl = '/_api/v1/translations/translate/';
    return getRequest(reqUrl, params);
});

Cypress.Commands.add('setUserData', (params, body, bearer) => {
    const reqUrl = '/api/v1/user/signup-info-data/';
    return postRequest(reqUrl, undefined, body, bearer);
});

These commands make it incredibly easy to add new API endpoints as needed. You’ll only need to define the endpoint URL and choose the appropriate HTTP method function.
I have created a separate file only for API custom commands. To be able to use it, I had to add import './commands-api' to the e2e.js file in the support folder.

Step 4: Using Custom Commands in Tests

With everything set up, using API requests in your tests becomes effortless. For example:

cy.getTranslation().then(response => {
    expect(response.status).to.eq(200);
    expect(response.body).to.have.property('translations');
});

Benefits of This Approach

Maintainability: Changes to API request logic (e.g., headers, logging) can be made in a single location.
Usability: Reuse the same custom commands across multiple tests.
Readability: Test files remain concise and focused on assertions.
Scalability: Easily add new endpoints or HTTP methods without duplicating code.

Conclusion

By organizing API requests into a general function, HTTP method-specific functions, and custom commands, you can significantly improve the maintainability and scalability of your Cypress API tests. This approach reduces code duplication and makes it easy to handle even complex testing scenarios.

Feel free to implement and adapt this structure in your projects. Let me know your thoughts or share your own approaches to organizing API requests in Cypress!

How To Simplify API Request Handling with Page Object Models in Cypress

Martin Chudomel — Sun, 15 Dec 2024 16:39:42 +0000

When writing Cypress tests, I often needed to use cy.intercept() and cy.wait() to monitor and assert specific API requests. However, I found myself repeatedly defining the same request interception in multiple tests. This repetition became a maintenance headache when the API URL changed, forcing me to update numerous test files.

To solve this, I applied the Page Object Model (POM) pattern, centralizing request interceptions and waits. This allowed me to manage API requests in one place, simplifying test maintenance and reducing code duplication.

The Problem: Repeated Interceptions

Here’s how my tests looked before adopting the POM approach:

it('Check trackings', () => {
    cy.intercept('GET', trackerUrl).as('tracker')
    cy.visit('/')
    cy.wait('@tracker').then((interception) => {
        expect(interception.request.body.registration.hashed_email).to.eq(hashed_email)
        expect(interception.request.body.registration.urid).not.to.be.undefined
    })
})

While this worked, the same request interception was duplicated across many tests.

The Solution: Centralizing in a Page Object Model

I moved the interception and wait logic into a POM class. Here’s how the updated test looks:

// don´t forget to import your page object model first
it('Check trackings', () => {
    homePage.interceptTracker()
    cy.visit('/')
    homePage.waitTracker().then((interception) => {
        expect(interception.request.body.registration.hashed_email).to.eq(hashed_email)
        expect(interception.request.body.registration.urid).not.to.be.undefined
    })
})

In the homePage object:

class HomePage {
    const trackerUrl = '...'

    // other functions

    interceptTracker() {
        return cy.intercept('GET', trackerUrl).as('tracker')
    }

    waitTracker() {
        return cy.wait('@tracker')
    }
}

const homePage = new HomePage()

When to Use Custom Commands

If the same interception logic applies to multiple pages or components, defining Cypress custom commands could be a better approach. This keeps your POMs cleaner while ensuring request handling is still centralized.

Key Takeaway

The Page Object Model isn’t just for managing UI elements. By applying it to request interceptions, I simplified API monitoring in Cypress tests and reduced maintenance effort. If you’re struggling with repetitive Cypress test logic, consider extending your POMs beyond UI elements!

How to Clean Up Cypress Command Log by Hiding Third-Party Requests

Martin Chudomel — Sun, 08 Dec 2024 15:15:58 +0000

Cypress is an excellent tool for end-to-end testing, but its command log can quickly become cluttered when your application makes numerous third-party XHR requests, such as ads or monitoring services. This can make debugging and troubleshooting harder.

To address this, I hacked Cypress’s command log to display only the requests directed at my application backend. The result? A much cleaner and more focused command log. In this article, I’ll explain how I did it and how you can implement it too.

Why Filter Third-Party Requests?

During testing, Cypress logs every request, including external ones like analytics and ads. While these requests are essential for the app's functionality, they aren't relevant for most Cypress tests. Filtering them out keeps the log readable and easier to follow.

The Solution: Hacking the Cypress Command Log

I created a script that dynamically observes the Cypress command log and hides third-party XHR and Fetch requests. You can toggle this feature using a custom hideThirdPartyRequestsflag in your Cypress configuration.

The Code

Add the following code to your e2e.js file in your Cypress support folder:

const app = window.top.document
const script = app.createElement('script');
const hideThirdPartyRequests = Cypress.config('hideThirdPartyRequests');
script.textContent = `
    function setupObserver(autoHideConsents, hideThirdPartyRequests) {
        const commandLog = app.querySelector('.reporter').querySelector('.container');
        if (commandLog) {
            const observer = new MutationObserver((mutations) => {
                mutations.forEach((mutation) => {
                    if (mutation.type === 'childList' && mutation.addedNodes.length > 0) {
                        mutation.addedNodes.forEach((node) => {
                            if (node instanceof Element) {
                                const commandInfo = node.querySelector('.command-info');
                                if (commandInfo) {
                                    const commandType=commandInfo.querySelector('.command-method').querySelector('span').textContent;
                                    if(commandType === '(xhr)' || commandType === '(fetch)'){
                                        const commandMessageText = commandInfo.querySelector('.command-message-text');
                                        const messageParts = commandMessageText.textContent.split(' ');
                                        const myUrl = messageParts[messageParts.length - 1];
                                        if(commandMessageText && myUrl){
                                            if (!myUrl.startsWith('/')) {
                                                node.style.display = 'none';
                                            }
                                        }
                                    }
                                }
                            }
                        });
                    }
                });
            });
            observer.observe(commandLog, { childList: true, subtree: true });
        }
        return false;
    }

    if (document.readyState === 'complete' && ${hideThirdPartyRequests}) {
    setupObserver();
    }
`;

app.head.appendChild(script);

How it Works?

1. Command Log Observation:

The script sets up a MutationObserver that listens for changes in the Cypress command log.

2. Filtering Logic:

Whenever a new request is logged, the script checks if it’s an XHR or Fetch request.
If the request URL does not start with /, it is considered a third-party request and gets hidden.

3. Toggle Control:

The hideThirdPartyRequests flag in cypress.config.js enables or disables the filtering.

Adding the Config Flag

To enable the feature, add the following line to your cypress.config.js:

module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      // Your setup here
    },
    hideThirdPartyRequests: true,  // Set to false to disable filtering
  }
};

The Result

With this hack in place, Cypress’s command log shows only the requests related to your backend. You’ll no longer have to scroll through irrelevant logs, making debugging a breeze!

Final Thoughts

This quick hack dramatically improved my Cypress testing experience by keeping the command log clean and relevant. While this approach works well for my projects, feel free to adapt the logic to fit your app’s request structure.

Have you tried something similar? Share your experience in the comments!

Create your own Cypress test results dashboard

Martin Chudomel — Sun, 01 Dec 2024 16:05:29 +0000

If you're like me, you appreciate the insights provided by Cypress Cloud but want to avoid the cost, especially for smaller projects or teams. This post walks you through how I created a cost-effective alternative using Cypress, Google Sheets, and Looker Studio. By the end of this article, you'll know how to collect and visualize automated test data efficiently.

When running automated tests, identifying flaky tests or consistently failing tests is crucial for maintaining test suite reliability. While Cypress Cloud offers a robust solution for this, it can be expensive. I wanted a free and straightforward way to track test runs, visualize failures, and find trends over time.

My Approach

I combined Cypress hooks, Google Apps Script, and Google Looker Studio to create a functional and flexible dashboard. Here's how it works:

Cypress collects data during test runs.
Google Sheets API acts as a lightweight database for storing test data.
Google Looker Studio visualizes this data for quick insights.

Step 1: Capturing Test Run Data in Cypress

I used the after:run event in cypress.config.js to gather information like test run duration, test names, failure states and folder locations.
Here's the Cypress configuration code in the cypress.config.js file:

on('after:run', async (results) => {
  function sendData(data, sheetName) {
    const options = {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(data),
    };

    const url = `https://script.google.com/macros/s/<your_script_id>/exec?sheetName=${sheetName}`;
    return fetch(url, options)
      .then(response => response.json())
      .catch(error => console.error('Error:', error));
  }

  if (process.env.CI) { // for tests running in CI only
    const runId = new Date().getTime();
    const runData = {
      values: [[runId, results.totalDuration, "KIM", results.totalTests, results.totalFailed, new Date().toISOString(), process.env.CI_SCHEDULE_NAME]],
    };
    await sendData(runData, "runData");

    const failedTests = results.runs.flatMap(run =>
      run.tests.filter(test => test.state === 'failed').map(test => ({
        runId,
        testName: test.title.join(' > '),
        testFile: run.spec.name,
        duration: test.duration,
        folder: run.spec.relative.split('\\').slice(-2, -1)[0],
      }))
    );

    if (failedTests.length > 0) {
      const values = failedTests.map(({ runId, testName, testFile, duration, folder }) => [runId, testName, new Date().toISOString(), testFile, duration, "KIM", folder]);
      await sendData({ values }, "testData");
    }
  }
});

Step 2: Creating a Google Apps Script for Data Storage

Google Sheets is a perfect lightweight database for storing structured data. I created a Google Apps Script to handle POST requests and write data to specific sheets.

Here's the script:

function doPost(e) {
  try {
    let sheetName = e.parameter.sheetName || 'dataKim';
    const sheet = SpreadsheetApp.openById('<your_sheet_id>').getSheetByName(sheetName);
    const data = JSON.parse(e.postData.contents);
    const values = data.values;

    sheet.getRange(sheet.getLastRow() + 1, 1, values.length, values[0].length).setValues(values);

    return ContentService.createTextOutput(
      JSON.stringify({ result: 'successfuly written', data })
    ).setMimeType(ContentService.MimeType.JSON);
  } catch (error) {
    return ContentService.createTextOutput(
      JSON.stringify({ result: 'error', error: error.message })
    ).setMimeType(ContentService.MimeType.JSON);
  }
}

Don´t forget to deploy your script first, after making changes to it.

To deploy:

Create a new script in your Google Workspace account.
Replace with your Google Sheet ID.
Publish the script as a web app with "Anyone with the link" access.

Step 3: Visualizing Data with Looker Studio

Looker Studio (formerly Google Data Studio) offers an intuitive way to visualize data stored in Google Sheets. It was my tool of choice, because our comapny uses Google products. Here's how I set it up:

Connect the Sheets: Import your Google Sheets containing test run and test data.

Build Charts: Use bar charts, line graphs, or tables to visualize metrics like failure rates, test durations, and the most frequently failing tests.
Filter and Explore: Add date ranges or filters to drill down into specific test suites or timeframes.

There is a plenty of other tools for data visualization. You can even use Google sheets alone.

Here is the result that our team at Hyperia is using:

Conclusion

Building this dashboard was a rewarding experience, enabling me to understand test results better and save money. If you're running Cypress tests on a budget, give this setup a try! You’ll be surprised at how much insight you can gain without premium tools.

Have you built something similar, or do you have tips to improve this setup? Let me know in the comments!

Forem: Martin Chudomel

The Cypress Variable Trap: When if Runs Too Soon in Your Tests

Scenario

The Catch

The reliable fix: Keep it in Cypress’ world

Side notes

Rule of thumb

Summary

Integrating Cypress with Jenkins API for Automated Test Preparation

Automating Pre-Test Jobs with Jenkins API

Starting a Jenkins Job

Waiting for jobs in queue

Monitoring Job Completion

Checking Queue Item Status

Implementing Specific Jenkins Commands

Using Jenkins Jobs in Cypress Tests

Expanding Possibilities for Automated Testing

How to Conditionally Skip Tests in Cypress the Right Way

The Common Pitfall

The Fix: Place the Condition Inside the Test Block

Alternative Approaches to Skipping Tests

1. Using Cypress.env() for Configuration-Based Skipping

2. Using this.skip() in a beforeEach Hook

3. Skipping Entire Suites Conditionally

Conclusion

Efficient Cypress API Testing with Custom Commands

Step 1: A General Function for All Requests

Step 2: Specific Functions for HTTP Methods

Step 3: Custom Cypress Commands

Step 4: Using Custom Commands in Tests

Benefits of This Approach

Conclusion

How To Simplify API Request Handling with Page Object Models in Cypress

The Problem: Repeated Interceptions

The Solution: Centralizing in a Page Object Model

When to Use Custom Commands

Key Takeaway

How to Clean Up Cypress Command Log by Hiding Third-Party Requests

Why Filter Third-Party Requests?

The Solution: Hacking the Cypress Command Log

The Code

How it Works?

Adding the Config Flag

The Result

Final Thoughts

Create your own Cypress test results dashboard

My Approach

Step 1: Capturing Test Run Data in Cypress

Step 2: Creating a Google Apps Script for Data Storage

Step 3: Visualizing Data with Looker Studio

Conclusion

1. Using `Cypress.env()` for Configuration-Based Skipping

2. Using `this.skip()` in a `beforeEach` Hook