DEV Community: Sehani Chathurangi

Building Mocks-First Automated Testing with Cypress and AWS DynamoDB

Sehani Chathurangi — Fri, 14 Aug 2026 10:10:37 +0000

When testing applications that depend on cloud services, manually preparing database records for every test can quickly become time-consuming, repetitive, and error-prone.

A better approach is to automate test-data creation using reusable fixtures, custom Cypress tasks, and the AWS SDK.

In this article, I'll walk through how I built a mocks-first testing approach using Cypress and AWS DynamoDB, where each test can create the data it needs, execute independently, and verify the resulting database state.

Why Mocks-First Testing?

A mocks-first approach allows tests to control their required data and dependencies instead of relying on manually prepared records.

Rather than creating database records before running a test, the test itself prepares the required state during execution.

This provides several benefits:

Faster test execution
Repeatable test scenarios
Reusable test data
Less manual setup
Better test isolation
Easier maintenance
More reliable CI/CD execution

The goal is not to mock every AWS service. Instead, the approach focuses on controlling test data and external dependencies so that tests remain predictable and repeatable.

The Overall Approach

The architecture can be summarized as:

Cypress Test → cy.task() → Node.js → AWS SDK → DynamoDB

The Cypress test is responsible for describing the scenario and assertions, while the Node.js layer handles AWS-specific operations.

This separation keeps the test code clean and prevents AWS database logic from being duplicated across test cases.

Step 1: Create Reusable Mock Data

The first step is to create reusable JSON fixtures.

cypress/
└── fixtures/
    └── test-data.json

The fixture contains the information required to create the database record.

Instead of hardcoding database values inside every test, the fixture becomes the base payload that can be reused across multiple scenarios.

For example:

{
  "id": "test-12345",
  "name": "Sample Test Data",
  "category": "TEST",
  "status": "ACTIVE"
}

Different fixtures can also be created for:

Positive scenarios
Negative scenarios
Boundary conditions
Error scenarios
Different transaction states

This keeps test data separate from test logic.

Step 2: Separate Database Logic

The next step is to keep DynamoDB operations outside the Cypress test itself.

A dedicated helper can be responsible for:

Creating the DynamoDB client
Converting fixture data into database records
Generating partition keys and sort keys
Calculating TTL values
Inserting records
Retrieving records
Deleting test data when required

For example, a helper might expose operations such as:

insertMockData()
getMockData()
deleteMockData()

The important principle is separation of concerns.

The test should describe what data it needs, while the helper handles how that data is stored in DynamoDB.

Step 3: Expose Database Operations Through Cypress Tasks

Cypress provides cy.task() as a bridge between the Cypress test environment and Node.js.

Instead of putting AWS SDK operations directly inside the browser-side test, the test can call a custom task:

cy.task('insertMockData', mockData);

The flow becomes:

Cypress Test
     │
     ▼
 cy.task()
     │
     ▼
 Node.js
     │
     ▼
 AWS SDK
     │
     ▼
 DynamoDB

Typical Cypress tasks can include:

insertMockData
getMockData
deleteMockData

This approach centralizes AWS operations and makes them reusable across the entire test suite.

Step 4: Configure Environment Variables

Cloud configuration should never be hardcoded inside test files.

Environment-specific values can be provided through configuration such as:

AWS Region
AWS credentials
DynamoDB table name
Local DynamoDB endpoint
Other environment-specific settings

This allows the same test suite to run against different environments.

For example:

Local
  ↓
Development
  ↓
QA
  ↓
CI/CD

The test logic remains unchanged while the configuration changes according to the execution environment.

Credentials and secrets should always be managed securely and should never be committed to the repository.

Step 5: Build Flexible Test Data

Creating a separate fixture for every test scenario can eventually lead to duplicated test data.

Instead, a base fixture can be loaded and overridden only where necessary.

For example:

const testData = {
  ...baseFixture,
  id: `test-${Date.now()}`,
  status: 'INACTIVE'
};

The base fixture provides the common structure, while the test customizes only the values relevant to the scenario.

This approach makes it easier to generate unique test records while keeping the fixture maintainable.

It is especially useful when testing:

Multiple transactions
Different statuses
Different merchants
Edge cases
Concurrent processing
Large datasets

Step 6: Verify the Database State

Creating test data is only part of the process.

After the application processes the data, the test should retrieve the relevant DynamoDB record and validate the resulting state.

Typical validations include:

Record exists
Partition key is correct
Sort key is correct
Required attributes are stored
Status is updated correctly
Configuration values match expectations
TTL is generated correctly
Expected processing results are persisted

For example:

Insert test data
       ↓
Application processes data
       ↓
Retrieve DynamoDB record
       ↓
Validate final state

This allows the test to validate not only that data can be written, but also that the application's workflow produces the expected result.

Why This Structure Works

The approach separates the test suite into three main responsibilities:

Fixtures
   ↓
Test Data

Database Helpers
   ↓
AWS / DynamoDB Operations

Cypress Tests
   ↓
Business Scenarios + Assertions

This separation provides a cleaner architecture and makes individual components easier to maintain.

If the DynamoDB implementation changes, the test cases do not necessarily need to change.

If the test scenario changes, the AWS helper does not need to change.

Moving Toward Event-Driven Testing

Directly inserting records into DynamoDB is useful for preparing controlled test states, but it can also bypass parts of the application's normal workflow.

This approach can therefore become the foundation for a more complete event-driven testing strategy.

The current approach might look like:

Fixture
   ↓
Cypress Task
   ↓
DynamoDB
   ↓
Application / Verification

The next evolution could be:

Fixture
   ↓
Event / SNS
   ↓
Application
   ↓
DynamoDB
   ↓
Cypress Verification

Instead of directly creating the database record, the same mock payload can be published as an event.

The application then processes the event through its normal workflow, and Cypress verifies the final database state.

The biggest advantage is that the test-data model can remain reusable.

The injection point changes, but the underlying fixture structure can remain largely the same.

When This Approach Is Useful

This pattern works particularly well for:

Integration testing
Event-driven applications
DynamoDB-backed services
CI/CD pipelines
Repeatable test scenarios
Large-scale automated test suites
Tests requiring controlled database state

However, direct database seeding should be used carefully for end-to-end testing because it can bypass application logic that you may actually want to validate.

A good testing strategy can use both approaches:

Database seeding for controlled setup and targeted integration tests.

Event/API-driven setup for validating the application's complete workflow.

Key Benefits

Using reusable fixtures together with Cypress tasks provides several advantages:

Cleaner test code — AWS logic stays outside the test cases.
Reusable mock data — Fixtures can support many scenarios.
Reduced duplication — Base data can be overridden when needed.
Faster execution — Tests do not depend on manual database preparation.
Better test isolation — Each test can create its own required state.
Centralized AWS logic — DynamoDB operations are maintained in one place.
CI/CD friendly — Test data can be generated automatically.
Easy evolution — The same data model can support future event-driven testing.

Final Thoughts

Automating database setup with reusable fixtures, Cypress tasks, and the AWS SDK can remove a significant amount of repetitive manual work from integration testing.

The key is to keep test data, database operations, and test scenarios separate.

Instead of manually preparing DynamoDB records before every test, the test suite becomes responsible for creating the state it needs and validating the resulting behavior.

More importantly, this approach creates a foundation for moving toward event-driven testing. As the application architecture evolves, the same reusable test data can be injected through events and processed through the application's normal workflow.

The result is a testing architecture that is repeatable, maintainable, scalable, and easier to integrate into CI/CD pipelines.

Connecting AWS Account with Cypress Automation: A Simple STS Connection Test

Sehani Chathurangi — Fri, 17 Jul 2026 12:42:14 +0000

When building Cypress automation that interacts with AWS services, the first step is verifying that your test framework can successfully authenticate and communicate with your AWS account.

In this article, you'll learn how to connect Cypress to AWS and perform a simple authentication test using AWS Security Token Service (STS) and the GetCallerIdentity API.

This approach helps confirm that:

AWS credentials are correctly configured.
Cypress can invoke AWS SDK operations through Node.js tasks.
The automation environment is connected to the expected AWS account.

Establishing this connection first provides a solid foundation before automating interactions with services such as AWS Lambda, Amazon S3, Amazon DynamoDB, Amazon SNS, or Amazon SQS.

Prerequisites

Before getting started, ensure you have:

Node.js installed
A Cypress project
Valid AWS credentials:
- AWS Access Key ID
- AWS Secret Access Key
- AWS Session Token (if using temporary credentials)
- AWS Region

Note:If you're running Cypress in an AWS environment (such as AWS CodeBuild, an EC2 instance with an IAM role, or GitHub Actions using OpenID Connect), you may not need to provide credentials manually. The AWS SDK can automatically retrieve credentials from the execution environment.

Step 1: Install the AWS SDK

Install the AWS STS client package:

npm install @aws-sdk/client-sts

For this connectivity test, we only need the AWS Security Token Service (STS) client.

The package provides:

STSClient – Creates a client for communicating with AWS STS.
GetCallerIdentityCommand – Returns details about the authenticated AWS identity associated with the configured credentials.

Step 2: Configure AWS Credentials

For local development, create or update your cypress.env.json file.

{
  "AWS_ACCESS_KEY_ID": "",
  "AWS_SECRET_ACCESS_KEY": "",
  "AWS_SESSION_TOKEN": "",
  "AWS_REGION": ""
}

Populate the file with your AWS credentials.

Example:

{
  "AWS_ACCESS_KEY_ID": "your-access-key",
  "AWS_SECRET_ACCESS_KEY": "your-secret-key",
  "AWS_SESSION_TOKEN": "your-session-token",
  "AWS_REGION": "us-east-1"
}

Important: Never commit cypress.env.json containing real AWS credentials to source control. Add it to your .gitignore file.

Best Practice: For CI/CD pipelines, prefer environment variables, IAM roles, or OpenID Connect (OIDC) instead of storing credentials in a file.

Step 3: Configure Cypress to Use AWS Credentials

Update your cypress.config.ts.

First, import the required AWS SDK classes.

import { defineConfig } from "cypress";
import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";

Inside setupNodeEvents, map the Cypress environment variables to Node.js environment variables.

setupNodeEvents(on, config) {

  const awsKeys = [
    "AWS_ACCESS_KEY_ID",
    "AWS_SECRET_ACCESS_KEY",
    "AWS_SESSION_TOKEN",
    "AWS_REGION",
  ] as const;

  for (const key of awsKeys) {
    if (config.env[key]) {
      process.env[key] = config.env[key];
    }
  }

}

Cypress stores environment variables in config.env, while the AWS SDK automatically reads credentials from the standard Node.js environment (process.env).

By copying the values into process.env, the AWS SDK can authenticate automatically without requiring any additional credential configuration.

The AWS SDK follows the AWS Credential Provider Chain, and environment variables are one of the first credential sources it checks.

Step 4: Create an AWS Connection Task

Create a Cypress task that authenticates with AWS using STS.

on("task", {
  async awsConnectionTest() {
    try {
      const client = new STSClient({
        region: process.env.AWS_REGION || "us-east-1",
      });

      const response = await client.send(
        new GetCallerIdentityCommand({})
      );

      return {
        Account: response.Account,
        Arn: response.Arn,
        UserId: response.UserId,
      };
    } catch (error) {
      throw new Error(`AWS authentication failed: ${error}`);
    }
  },
});

Why use a Cypress task?

AWS SDK calls must run in Cypress tasks because tasks execute in the Node.js process.

Cypress test code runs in the browser context, where direct access to Node.js APIs is not available. Using cy.task() allows your tests to securely execute backend operations such as invoking AWS services.

What happens during this task?

Cypress calls the awsConnectionTest task.
The AWS SDK creates an STS client using the configured region.
The SDK automatically resolves credentials from the environment.
AWS validates the credentials.
STS returns details about the authenticated IAM user or role.

A successful response looks like this:

{
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/test-user",
  "UserId": "AIDAxxxxxxxx"
}

Step 5: Create a Cypress Test

Create a new test file.

testing/awsConnection.cy.ts

Add the following test:

describe("AWS connection", () => {

  it("connects to AWS using STS GetCallerIdentity", () => {

    cy.task("awsConnectionTest").then((identity) => {

      cy.log(JSON.stringify(identity));

      expect(identity).to.have.property("Account");
      expect(identity).to.have.property("Arn");
      expect(identity).to.have.property("UserId");

    });

  });

});

Step 6: Run the Cypress Test

Execute either of the following commands:

npx cypress open

npx cypress run

If authentication is successful, Cypress logs the authenticated AWS identity, including:

AWS Account ID
IAM User or Role ARN
User ID

This confirms that Cypress can successfully authenticate with your AWS account.

Why Start with GetCallerIdentity?

Before interacting with AWS services such as:

AWS Lambda
Amazon S3
Amazon DynamoDB
Amazon SNS
Amazon SQS

it's recommended to verify that authentication is working correctly.

GetCallerIdentity is ideal because it:

Confirms that authentication is successful.
Identifies the AWS account and IAM identity being used.
Helps diagnose credential-related issues early.
Does not require permissions beyond the ability to authenticate.

Conclusion

Successfully calling GetCallerIdentity confirms that Cypress can authenticate with AWS using the configured credentials.

In this article, you learned how to:

Install the AWS STS SDK.
Configure AWS credentials for local development.
Map Cypress environment variables to the Node.js environment.
Create a Cypress task that authenticates with AWS.
Validate the connection using GetCallerIdentity.

Once this authentication step is working, you can extend the same approach to automate testing against other AWS services such as Lambda functions, S3 buckets, DynamoDB tables, SNS topics, SQS queues, and many more.

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.