Forem: Sehani Chathurangi

Reusing Dynamic Values in Cypress Tests: Store Once, Reuse Anywhere

Sehani Chathurangi — Fri, 11 Jul 2025 03:54:11 +0000

In test automation, maintaining and reusing state between test cases is essential for creating efficient, end-to-end workflows. When writing Cypress tests that interact with APIs, it's common to receive dynamic data from a response—such as an ID, token, or reference number—that you'll need to use in a later request. Instead of hardcoding or repeating logic, Cypress allows you to store these values temporarily during the test run and reuse them wherever needed.

Let’s explore how to do this in a clean and efficient way.

Why Store Values Dynamically?

Many real-world scenarios involve multi-step processes where the output of one step is the input for the next. For instance:

A request may return an identifier (id) that’s required for the next API call.
A system may provide an access token that must be included in subsequent headers.
You might need to retrieve the status of a resource using a previously returned reference.

By reusing these variables, you:

Reduce redundancy: Avoid recreating the same data in every test.
Improve performance: Skip repetitive setup steps.
Mimic real-world workflows: Simulate multi-step user journeys.

01.Use Cypress.env() to Store and Reuse Data

Cypress provides a convenient way to store values in memory using Cypress.env() during a test run.

Store the Value

When you receive a value from an API response, you can store it like this:

cy.request('POST', 'your-api-url', requestBody).then((response) => {
  const dynamicId = response.body.id;
  Cypress.env('dynamicId', dynamicId); // Save it temporarily
});

Reuse It in Another Request

You can then access that value in a later test step:

cy.request({
  method: 'GET',
  url: `your-api-url/${Cypress.env('dynamicId')}`,
  headers: {
    Authorization: `Bearer yourAccessToken`,
  },
}).then((response) => {
  expect(response.status).to.eq(200);
  // more assertions
});

Example with Tokens

Here’s how to store an access token received from an authorization request:

cy.request('POST', 'token-url', credentials).then((response) => {
  const token = response.body.access_token;
  Cypress.env('accessToken', token); // Stored in memory
});

Use it later:

cy.request({
  method: 'GET',
  url: 'api/secure-data',
  headers: {
    Authorization: `Bearer ${Cypress.env('accessToken')}`, // Used here
  },
});

02.Using Test-Specific Variables

For data needed only within a single test file, use closures (e.g., let variables).

Example: Reusing a Resource ID

describe('Reusing ResourceID Tests', () => {
  let resourceId; // Accessible across all tests in this describe block
  it('Creates a Resource', () => {
    cy.request('/resources', { method: 'POST' }).then((response) => {
      resourceId = response.body.id; // Assign ID
    });
  });
  it('Validates the Resource', () => {
    cy.request(`/resources/${resourceId}`).then((response) => {
      expect(response.status).to.eq(200);
    });
  });
});

03. External Storage (Files, Databases)

For cross-suite or cross-run persistence, save data to files (e.g., JSON) or databases. Use this sparingly, as it introduces external dependencies.

Good Practices

Use Cypress.env() for temporary values within the same test suite.
Do not use Cypress.env() as a way to persist values between test files.
Store static configuration in cypress.env.json, but store dynamic values using Cypress.env() at runtime.
Clean Up State: Delete test data after runs (e.g., in after hooks).
Avoid Hardcoding Values: Use environment variables or configuration files for URLs, keys, etc.
Handle Asynchronous Flows: Use cy.wait() or retry logic if systems need time to process data.

Summary

Storing dynamic data during test execution helps avoid hardcoding and keeps your Cypress tests clean and reliable. By leveraging Cypress environment variables, closures, or external storage, you can build robust test suites that minimize redundancy and maximize efficiency. Always prioritize clarity and maintainability—use descriptive variable names and document shared state dependencies. This approach improves test reusability, enhances readability, and supports more complex workflows in your automation suite.

👉 For more articles like this, visit my site: https://careersuccesso.com/

Mastering Test Flow Control with Cypress.stop()

Sehani Chathurangi — Tue, 29 Apr 2025 15:18:08 +0000

Cypress is a powerful tool for end-to-end testing, but sometimes you need to halt execution immediately when a critical failure occurs. Enter Cypress.stop(). This command stops all test execution, ensuring you avoid cascading failures or wasted resources when a prerequisite fails. Let’s explore how to use it effectively. When working with automated tests in Cypress, efficiency is everything—especially when you're running large test suites across multiple environments or CI pipelines. That’s where Cypress's Cypress.stop() method becomes incredibly useful.

What is Cypress.stop()?

Cypress.stop() halts the Cypress Test Runner mid-execution. It’s a manual switch to stop running any remaining tests in the current spec file.

It can be incredibly handy in situations like:

When an essential precondition fails (e.g., token generation, environment setup)
When you want to stop on the first failure
To prevent redundant test execution during debugging or early failure diagnosis

Syntax

Cypress.stop()

Example Scenario: Stop Test Run on Token Generation Failure

Let’s say you’re working on API tests.

In this API test, Cypress.stop() is used to halt execution if an access token can’t be generated. Without this token, other tests verifying are meaningless. Here’s the breakdown:

it('Generates an Access Token', () => {
  cy.request({
    method: 'POST',
    url: `${Cypress.env('baseUrl')}`,
    headers: {
      'subscription-Key': `${Cypress.env('subscriptionKey')}`,
      Authorization:
        'Basic ' +
        btoa(
          `${Cypress.env('apiUser')}:${Cypress.env('apiKey')}`
        ),
    },
    failOnStatusCode: false,
  }).then((response) => {
    if (response.status !== 200 || !response.body.access_token) {
      cy.log('Access token generation failed!');
      Cypress.stop(); //Stop remaining tests in the file
    }
    cy.log(‘Access token generated successfully');
    Cypress.env('accessToken', response.body.access_token);
  });
});
// ... other tests that depend on the access token

Stop Tests After Any Failure

If you want to automatically stop the test run on any failure, add this to your automation script:

afterEach(function () {
  if (this.currentTest.state === 'failed') {
    Cypress.stop();
  }
});

Behavior Differences: cypress run vs cypress open

cypress run (CI mode):Cypress.stop() halts execution of the current spec file, but the app continues running and uploads all test results.

cypress open (Interactive mode): Cypress will stop executing tests but keep the Test Runner open for inspection.

Why This Works

Fail-Fast Principle: The test suite stops immediately on token failure, avoiding false negatives in later steps.
Clear Diagnostics: Logs the failure and stops execution, making debugging easier.

When to Use Cypress.stop() vs. cy.skip()

Cypress.stop():

Nuclear option: Stops ALL tests.
Use when no further tests can proceed (e.g., missing tokens, broken environments).

cy.skip():

Skips a single test or block.
Use when a test is conditionally irrelevant (e.g., a feature flag is off).

Cypress.stop() is simple but powerful for controlling your test flow when you know something has gone wrong. It's especially useful during development or in CI pipelines to avoid wasting resources.

Cypress.stop() is your emergency brake for tests. By using it in scenarios like failed logins, broken API handshakes, or missing environment variables, you keep your test results clean and actionable. Pair it with robust error logging, and you’ll streamline your debugging process while saving time and resources.