DEV Community: Daniil

How to handle drag and drop with Cypress in Workflow Builder

Daniil — Tue, 13 Jan 2026 03:49:13 +0000

Drag’n’drop is one of those UI interactions that used to feel painful to automate.
Rarely used, often avoided… but very real in modern products, especially a Agentic Workflow Builders like Opus or n8n, OpenAI, Monday.com, etc.

Workflow builders, canvas editors, node-based UIs — like Opus — rely on it heavily.

The good news: Cypress (with the right approach) handles this surprisingly well.

Two main ways to do drag’n’drop in Cypress

Native browser events

.trigger("mousedown")
.trigger("mousemove")
.trigger("mouseup")

This gives you full control over coordinates and is perfect for:

canvas-based UIs
node connectors
custom drag logic

Cypress-real-events plugin

Closer to real user behavior and great for classic UI drag cases.

Real-world example: connecting nodes on a canvas.

This is how I automate workflow connections in Opus

// Cypress Custom Command to connect workflow units - Tasks(Nodes).

Cypress.Commands.add("connectNodes", (outputSelector, inputSelector, numberOfEdges) => {
  function getCenterCoords($el) {
    const rect = $el[0].getBoundingClientRect();
    return {
      x: rect.x + rect.width / 2,
      y: rect.y + rect.height / 2,
    };
  }

  cy.get(outputSelector).then(($out) => {
    const { x: outX, y: outY } = getCenterCoords($out);

    cy.get(inputSelector).then(($in) => {
      const { x: inX, y: inY } = getCenterCoords($in);

      cy.wrap($out)
        .trigger("mousedown", { button: 0, clientX: outX, clientY: outY, force: true })
        .trigger("mousemove", { clientX: inX, clientY: inY, force: true });

      cy.wrap($in).trigger("mouseup", { force: true });

      cy.get("[data-test-id='edge']")
        .should("exist")
        .and("have.length", numberOfEdges);
    });
  });
});

This approach lets tests build workflows automatically, just like real users do.

And bonus: file uploads.
While it seems to be the same method, it really depends on which packages your product is using. So there is 2 approaches:

.selectFile() - built-in way to select files in an HTML5 input element & simulate dragging files into a browser with the .selectFile()
Native browser events:

.trigger("dragenter")
.trigger("dragover")
.trigger("drop")

// Cypress Custom Command to drag'n'drop file into upload area, e.g. React Aria DropZone

Cypress.Commands.add(
  "dragAndDropUploadFile",
  (fileName, targetSelector, mimeType = "application/json") => {
    cy.intercept("POST", "/job/file/download").as("fileDownload");

    cy.fixture(`sampleFiles/${fileName}`, "base64").then((fileContent) => {
      const blob = Cypress.Blob.base64StringToBlob(fileContent, mimeType);
      const testFile = new File([blob], fileName, { type: mimeType });

      const dataTransfer = new DataTransfer();
      dataTransfer.items.add(testFile);

      cy.get(targetSelector)
        .trigger("dragenter", { dataTransfer })
        .trigger("dragover", { dataTransfer })
        .trigger("drop", { dataTransfer });
    });
    // Verify status of the upload process with custom command
    cy.verifyApiStatus("@fileDownload", 201);
  },
);

Key takeaway

Drag’n’drop isn’t just about moving pixels.
It’s about testing user intent, state transitions, and real AI workflows.

Once you stop avoiding it — Cypress gives you everything you need.

Next up: more canvas, workflow, and agentic UI testing patterns 👀

How do you handle drag’n’drop in your tests?

cy.prompt() Changes UI Testing Forever. How it works under the hood

Daniil — Tue, 14 Oct 2025 12:50:38 +0000

The Pain We’ve All Felt

If you’ve ever tested a Shadow DOM component or a slotted element, you know the pain.

Finding the right selector sometimes feels like archaeology - digging through browser dev tools, retries, custom commands in the dev console, and then one day… a UI redesign breaks it all again…

I’ve personally spent hours writing helpers just to find one stubborn element inside a Shadow Root which was slotted at the same time.
And every time, I thought:

“There must be a simpler way to tell the test what I mean.”

The Breakthrough - `cy.prompt()`

I think some QA Gods and #cypress product team heard me. Now, there is cy.prompt() !
With cy.prompt(), you can literally describe what to test, and Cypress with AI assistance will translate it into executable test code.

//test-login.spec.js

cy.prompt([
  "Navigate to '/login' // with baseUrl set
  "Fill email in the shadow email input and submit"
  "Verify error message 'Password is required' is displaying below the password input field in the shadow DOM"
]);

Cypress runs this step, finds stable selectors under the hood, and caches them for speed.
If the DOM changes, it can self-heal by regenerating selectors automatically.

No more guessing, no more brittle selectors, no more “why did this break again?”.

Shadow DOM & Slotted Elements Example

Before I had to write custom Cypress commands just to get correct slotted UI element from a Shadow DOM. And my code looked like this:

And then I had to use that in my test

And now...wait for it...

//test-login.spec.js

cy.prompt("Fill email in the shadow email input and submit");

Same action, one line — and it understands nested DOM structures too.
That’s what makes this release so huge.

🥒 Works with Gherkin & Cucumber

If you’re using Cucumber and have a perfect-written Gherkin from you PM or PO, this is where it gets really interesting.

Cypress can now map your plain English steps directly to real actions.

gherkin

Given I log in with a valid user

can become:

cy.prompt("Log in with a valid user")

But I would still recommend to use the Golden Rule: Don’t mix business rules and test code in plain text.

You still want your custom commands and good test design - cy.prompt() is a boost, not a replacement.

Quick Comparison

Before

Complex, verbose test code
Heavy selector maintenance
Manual test updates
Cucumber integration needs mapping

After

One clear, natural-language step
Auto-generated, cached selectors
AI-assisted self-healing
AI maps English → test commands
AI suggestions if your prompt is weak for execution
Cashed runs if DOM not changed → better test performance

Current Limitations

It’s not magic (yet):

Works only with UI, not API assertions.
Still experimental — needs your feedback.
Generated code should be reviewed before committing.

But even now, it’s a massive leap forward in software test automation experience, though!

cy.prompt() feels like the moment automation starts listening to us.
It bridges natural language, AI, and test logic — while keeping the power of Cypress intact.

As someone who fought Shadow DOM selectors for years, I can honestly say that I’ve never written reliable UI tests this fast before.

Finding out what's next for cy.prompt()

Would you use cy.prompt() in your daily workflows or wait until it matures a bit more?

Follow my Telegram Channel for more insights. I share everything there first: Software Tester's Notes

And my YouTube Channel:

🥷 Shadow DOM in Test Automation: A Practical Guide with Cypress

Daniil — Wed, 24 Sep 2025 05:56:46 +0000

When testing web apps, the DOM is not always as straightforward as it looks.
Sometimes the element you “see” in DevTools isn’t accessible to your test. Why? Because it’s wrapped inside iframes or shadow DOM.

In this article, let’s break down what shadow DOM is, why it matters, and how you can test it with Cypress.

What is Shadow DOM?

Shadow DOM is an encapsulated subtree of the DOM that lives inside a host element.

It was introduced as part of the Web Components spec and is widely used in modern UI libraries (Material UI, Ionic, Lit, Angular components).

Key benefits:

CSS and JS are scoped (no global leaks)
Components are reusable
Structure is hidden from the “main” DOM

Think of it as a mini DOM inside the DOM.

Types of Shadow DOM

Normal DOM (baseline)

<div id="login">
  <input id="username" />
</div>

Cypress:

cy.get('#username').type('hello')

Shadow DOM (open)

<my-login>
  #shadow-root (open)
    <input id="username" />
</my-login>

Option A: Use .shadow() in Cypress

cy.get('my-login')
  .shadow()
  .find('#username')
  .type('hello')

Option B: Enable globally in cypress.config.js

module.exports = {
  e2e: {
    includeShadowDom: true
  }
}

Shadow DOM (closed)

<my-login>
  # — - > shadow-root (closed)
    <input id="username" />
</my-login>

⚠️ Closed shadow roots cannot be accessed with Cypress or regular query selectors.
They are designed to be private.
Workaround: you’ll need to use component-level testing, or rely on app exposing test hooks (e.g. props or attributes).

Slotted Elements

Sometimes elements are “projected” into a shadow DOM via a slot:

<my-login>
  #shadow-root (open)
    <slot name="email"></slot>
</my-login>

<input slot="email" id="email-input" />

Custom Cypress command:

Cypress.Commands.add('getSlottedElement', (selector) => {
  return cy.get(selector).then(($el) => {
    return cy.wrap($el[0].assignedNodes()[0])
  })
})

Usage

cy.getSlottedElement('#email-input').type('hello@qa.com')

Why Shadow DOM Matters in Automation

It’s everywhere in modern SPAs and Web Components
Your tests may fail with “element not found” unless you account for it
Handling shadow DOM properly makes tests stable and future-proof

Remember that:

DOM ≠ always accessible elements
Web apps can include: plain DOM, iframes, Shadow DOM (open/closed)
Cypress supports open shadow DOM with .shadow() or includeShadowDom config property
For slotted elements, you may need custom helpers. .shadow() can’t see slotted content directly, because it lives outside the shadow root and is just projected into it
For closed shadow DOM, collaborate with devs for test hooks

If you’re new to automation:
Start experimenting with Cypress and a simple Web Component demo.
You’ll quickly see why handling
shadow DOM is a must have skill.

Why your Telegram bot test is failing silently

Daniil — Tue, 27 May 2025 05:47:27 +0000

Telegram app logo is seen in this illustration taken, Aug 27, 2024.
Image: Reuters file

Sometimes the problem isn’t in your test code — it’s in how Telegram handles updates.

If your bot is running locally in polling mode, and your test also tries to read updates — nothing will break… but nothing will work either.

Let me explain what happened — and why this behavior is easy to overlook when you're just starting to test Telegram bots as myself.

The Problem

I was writing a test for the /start command using pytest.
The bot was running locally, the token was valid, everything looked fine — but the test was just...waiting.

Turns out, the issue wasn’t in the code — it was in the way Telegram’s getUpdates API works.

Here’s what was really going on:

My bot was running with .run_polling(), which continuously polls getUpdates in the background.
My test was also calling getUpdates manually, expecting to retrieve the /start command from a real Telegram chat.
The result? A hidden conflict.

Telegram only allows one active consumer of updates.

So when the bot is running, it “eats” all updates — and the test sees nothing.

🛠️ How to Fix It

Since you can’t simulate a user sending /start directly through the Telegram API (that’s forbidden), here are two reliable alternatives:

Option 1: Manual Trigger + Stored Log Verification
Best for CI or webhook-based bots.

You manually send /start from Telegram.
Your bot processes it and logs the result.
Your test waits briefly, then checks the log file or database to confirm the expected output.

Option 2: Simulate Telegram webhook with a fake payload

A fully automated way using requests.post() or similar to mock a real Telegram update:

You run your bot in webhook mode (instead of polling).
Telegram would normally send POST requests to your webhook URL (e.g. https://abc123.ngrok-free.app/webhook)
Instead, your test simulates this POST request using your own payload.
Your Flask or FastAPI app receives it and behaves as if it came from Telegram.

But why do I need Flask or FastAPI at all?

When using webhooks, Telegram sends updates to your bot as HTTP POST requests.

To receive them — you need a web server.

That’s where Flask or FastAPI comes in.
They expose an endpoint like /webhook that can receive and process Telegram’s payloads.

Webhook flow:

Telegram sends an update: POST https://yourdomain.com/webhook
Flask/FastAPI receives it and hands it over to python-telegram-bot
Your handler function is called just like in polling mode

Without this, your bot simply won’t work in webhook mode — and you won’t be able to test real-world flows in CI/CD.

Testing Telegram bots has its nuances and bottlenecks, and this one was a surprise for me too.

But the deeper you go — the more power you unlock.
This case alone pushed me to explore better testing strategies and architect a more production-like setup, even for test automation.

Would you be interested in more deep-dives on Telegram bot testing?

Let me know in the comments or drop a DM — I’m currently building a courses on this topic using Pytest, Playwright, and Cypress.

Parallelizing Cypress Tests in CI/CD with Jenkins, Docker, and K8s

Daniil — Tue, 22 Apr 2025 14:06:34 +0000

TL;DR

Learn how to run Cypress tests in parallel using Jenkins CI, Docker, and Kubernetes.
There are plenty of guides out there showing how to run Cypress tests in parallel using CI/CD tools like GitHub Actions, GitLab CI, CircleCI, and Jenkins.

But what if I told you that you can take it one step further—and integrate Kubernetes?
Yes, you read that right. You can run your tests across multiple pods to massively speed up execution using K8s.

🔧 Tools Used

Cypress Dashboard (for parallelization logic).
Jenkins CI (or any similar CI like GitHub Actions).
Docker (to pin Node/Chrome versions).
Kubernetes (to run multiple Cypress pods).

Project structure

│cypress/
│   └── e2e/
│       └── testsuite1.spec.js
│       └── ……
├── cypress.config.js
├── Dockerfile
├── Jenkinsfile
└── k8s/
    └── cypress-job.yaml

Step 1: Cypress setup with parallelization

Create a basic Cypress project on Cypress Cloud to enable parallelization logic
Grab your project ID and record key.
Follow Cypress Dashboard rules to connect your Cypress framework to the Dashboard by explicitly defining project ID in your config file and adding cypress key to your CLI command that run test execution

cypress.config.js

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

module.exports = defineConfig({
  // Your projectId from Cypress Dashboard project settings:
  projectId: "xyz123", 
  e2e: {
    ……
  },
});

Your CLI command will look something like this

npx cypress run --headless --record --key ${{your-secure-record-key-from-Cypress-Dashboard}} --parallel --group regression --ci-build-id ${{BUILD_NUMBER_GENERATED_BY_CI_PROVIDER}} —-env url=${{test-env-variable}}

I use additional flag —-env url= since I run tests on multiple environments. But you can exclude that.

Step 2: Create a Dockerfile

I normally use original Dockerfile from Cypress itself.

dockerfile

# Use Cypress included image matching package.json version
FROM cypress/included:14.0.1

# Set working directory to root (where config files reside)
WORKDIR /

# Copy package files and all config files to root
COPY package.json package-lock.json cypress.*.config.js ./

# Install dependencies and ensure Cypress binary is downloaded
RUN npm ci && \
    npx cypress install --force && \
    ls -l /root/.cache/Cypress/14.0.1/Cypress/Cypress || echo "Binary install failed"

# Copy the rest of the project files
COPY . .

# Default environment variables (can be overridden)
ARG ENVIRONMENT=stage
ARG CYPRESS_KEY
ARG TEST_FILE=""

ENV CYPRESS_ENVIRONMENT=$ENVIRONMENT
ENV CYPRESS_RECORD_KEY=$CYPRESS_KEY
ENV TEST_FILE=$TEST_FILE

# Default command (will be overridden in pipeline)
CMD ["npx", "cypress", "run", "--headless", "--record", "--key", "$CYPRESS_RECORD_KEY", "--env", "url=$CYPRESS_ENVIRONMENT"]

Step 3: Create a Jenkinsfile

In my case I re-use common template that has been made for each and every repo CI pipeline on our product, so I just needed to refer to shared lib.
But you follow your own company policies. The Jenkins template would be

groovy

pipeline {
  agent any
  environment {
    CYPRESS_RECORD_KEY = credentials('cypress-key')
    BUILD_ID = "${env.BUILD_NUMBER}"
  }
  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }
    stage('Run Cypress Tests in Parallel') {
                steps {
                    script {
                        def environmentToUse = params.ENV_NAME ?: 'stage'
                        def keyToUse = environmentToUse == 'stage' ? cypressKey : cypressKeyDev
                        def configFile = "cypress.${environmentToUse}.config.js"
                        echo "Using Cypress config file: ${configFile} for environment: ${environmentToUse}"

                        def testFiles = sh(script: """#!/bin/sh
                            find cypress/e2e -name '*.spec.js' 2>/dev/null || echo "No test files found"
                        """, returnStdout: true).trim().split('\n').findAll { it && it != "No test files found" }

                        if (!testFiles) {
                            error "No Cypress test files (*.spec.js) found in cypress/e2e directory!"
                        }
                        echo "Found ${testFiles.size()} test files: ${testFiles.join(', ')}"
                        def numContainers = Math.min(testFiles.size(), 8)

                        def parallelTasks = [:]
                        for (int i = 0; i < numContainers; i++) {
                            def startIdx = (i * testFiles.size() / numContainers).toInteger()
                            def endIdx = ((i + 1) * testFiles.size() / numContainers).toInteger()
                            def subset = testFiles[startIdx..<endIdx]
                            def podLabel = "cypress-test-${UUID.randomUUID().toString()}"

                            parallelTasks["cypress-${i}"] = {
                                podTemplate(label: podLabel, yaml: """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: cypress
    image: ${imageName}
    command:
    - cat
    tty: true
    resources:
      requests:
        memory: "2Gi"
        cpu: "1"
      limits:
        memory: "3Gi"
        cpu: "1.5"
""") {
                                    node(podLabel) {
                                        container('cypress') {
                                            sh script: """#!/bin/sh
                                                ls -l /root/.cache/Cypress/14.0.1/Cypress/Cypress || echo "Binary not found"
                                                ls -l /${configFile} || echo "Config file not found"
                                                cd /
                                                npx cypress run --headless --record --key ${keyToUse} --parallel --group "regression" --ci-build-id "${env.BUILD_NUMBER}" --env url=${environmentToUse} --config-file ${configFile}
                                                echo "${env.BUILD_NUMBER}"
                                            """
                                        }
                                    }
                                }
                            }
                        }
                        parallel parallelTasks
                    }
                }
            }
      }
    }
  }
}

Step 4: Define a Kubernetes Job

The most complicated step I would say.

Cypress test command should remain consistent between your Jenkinsfile and the Kubernetes Deployment or Job YAML file.
You may ask Why? Because Cypress uses the --record, --parallel, and --ci-build-id flags to coordinate and split specs across machines (or pods in our case).

So:

Jenkins is responsible for triggering the build and setting environment variables.
Kubernetes is responsible for running the actual test command inside pods.

Step 4a: How to securely pass CI_BUILD_ID and CYPRESS_RECORD_KEY

You should not hard-code sensitive values in YAML files or source control.

Use Kubernetes secrets instead:

bash

kubectl create secret generic cypress-secrets \
  --from-literal=CYPRESS_RECORD_KEY=your-record-key \
  --from-literal=CI_BUILD_ID=your-ci-build-id

Reference them in your YAML file as environment variables
k8s/cypress-job.yaml

yaml

env:
  - name: CYPRESS_RECORD_KEY
    valueFrom:
      secretKeyRef:
        name: cypress-secrets
        key: CYPRESS_RECORD_KEY
  - name: CI_BUILD_ID
    valueFrom:
      secretKeyRef:
        name: cypress-secrets
        key: CI_BUILD_ID

In your test command inside the container, use the same npx cypress run ... as in Jenkins.

apiVersion: batch/v1
kind: Job
metadata:
  name: cypress-parallel-job
spec:
  parallelism: 3
  completions: 3
  template:
    spec:
      containers:
        - name: cypress-runner
          image: cypress/browsers:node-18.12.0-chrome-123.0.6312.86-1
          command: ["/bin/sh", "-c"]
          args:
            - >
              npm ci &&
              npx cypress run \
              --record \
              --key $(CYPRESS_RECORD_KEY) \
              --parallel \
              --group "regression" \
              --ci-build-id $(CI_BUILD_ID) \
              --browser chrome
          env:
            - name: CYPRESS_RECORD_KEY
              valueFrom:
                secretKeyRef:
                  name: cypress-secrets
                  key: CYPRESS_RECORD_KEY
            - name: CI_BUILD_ID
              valueFrom:
                secretKeyRef:
                  name: cypress-secrets
                  key: CI_BUILD_ID
      restartPolicy: Never

parallelism: 3 - Defines how many pods run in parallel
completions: 3 - Defines how many successful completions are required for the job to be considered complete. Each successful pod counts as one completion.

Normally, Cypress Dashboard will show you how many machines are needed for the fastest execution

IMPORTANT: Each pod in this setup runs the same command, so to avoid duplicating test effort, you need Cypress’s --parallel and --ci-build-id logic to coordinate test distribution across those pods. They have to use same command and same secrets

Step 4b: 🚀 How Kubernetes runs multiple pods for parallel tests

When using --parallel in Cypress and deploying tests via Kubernetes, each pod acts as one parallelized "machine" for Cypress Dashboard to split test specs.

You can use a Kubernetes Job or Deployment with a replicaCount or control pod spawning using a custom script:

Option A: Static replicas (simpler)

spec:
  replicas: 4 # Number of parallel test runners

Option B: Dynamic pods based on spec count (advanced)

You can write a pre-step script (in Jenkins or elsewhere) that:

Counts the number of Cypress spec files.
Decides how many pods are needed.
Adjusts the Job YAML using envsubst or sed, or a Helm chart.
Applies the modified YAML via kubectl apply -f.

Step 5: Managing memory & resource allocation

Use resources in YAML to allocate CPU and memory for each pod:

yaml

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

If Cypress tests are heavy:

Start with 1Gi per pod and adjust based on OOM kills or slowness.
Use Node Autoscaler to spin up new nodes if cluster can't handle the load.
Or use Cluster Autoscaler on AWS EKS / GCP GKE / Azure AKS.

🛠️ Bonus: Auto-Scaling with a custom script

Use a script (Node.js, Bash, or Python) to:

This lets you scale parallel runs dynamically without hardcoding pod counts.

Detect the number of .spec.js files.
Set a max pod count per node.
Patch a YAML template using envsubst or a Helm chart.
Apply it to the cluster with kubectl.

Final Thoughts

Running Cypress tests in parallel isn’t just an optimization - it’s a game changer when it comes to test execution time and CI/CD scalability.

By combining:

Cypress Cloud’s built-in parallelization logic
Jenkins for CI orchestration
Docker to lock down your test environment
Kubernetes to scale execution across multiple pods

you get a powerful, maintainable, and cloud-native testing setup.

🔐 Secure parameter passing with Kubernetes Secrets
⚡ Dynamically spin up multiple pods for faster test runs
💡 Keep Cypress logic consistent across local, CI, and K8s

Whether you're scaling out your test suite, trying to reduce feedback loops, or modernizing your dev pipeline—this approach gives you the tools to move fast without breaking things.

Getters vs. functions in Cypress: The best practice you need to know

Daniil — Mon, 17 Feb 2025 19:39:48 +0000

Recently I've observed that some of us, QA Automation engineers, are still using getters in their test automation frameworks with Cypress.
When working with the Page Object Model in Cypress (Yes, you could use POMs if your web application is big, has a lot of micro services, micro frontends, and plenty of configurations and settings), you might come across two ways to define element selectors:

getters (get);
functions (method()).

Cypress works differently from Selenium & Playwright

Cypress executes commands asynchronously, meaning .get() does not return an element immediately like in Selenium or Playwright. Instead, Cypress commands are added to an internal queue and resolved automatically when Cypress executes them.
It means that getters won’t work as expected when trying to interact with elements.

Example of a getter (incorrect approach in Cypress)

class LoginPage {
  get usernameField() {
    //Cypress does NOT return an element immediately:
    return cy.get('#username'); 
  }
}

This fails because Cypress does not return an immediate element reference. Instead, it returns a Cypress chainable object, which requires further chaining for interactions like .type(), .click(), or .should(). Instead, they return a Cypress chain that must be resolved in Cypress' command queue.

Why getters fail in Cypress

Using getters in Cypress is problematic because:

Cypress commands are not immediately resolved

Cypress chains commands and executes them sequentially. Getters try to return an element immediately, which breaks Cypress' execution model.

Getters create unexpected behavior

Since Cypress commands don’t return actual values, writing like

LoginPage.usernameField.type('testuser')

will fail because usernameField does not return an immediate element.

Lack of explicit execution

Cypress follows a declarative approach, where you describe what should happen, and Cypress handles the execution. Getters hide Cypress commands inside properties, making it harder to debug.

The correct approach: use functions instead

Instead of getters, define element selectors as functions. This ensures Cypress correctly waits for elements before interacting with them.

Correct Page Object Model with function approach

Option 1 - Returning a Cypress command for chaining

class LoginPage {
  usernameField() {
    return cy.get('#username');
  }

  passwordField() {
    return cy.get('#password');
  }

  loginButton() {
    return cy.get('#login');
  }
}

Now, you can use it correctly in your tests:

const loginPage = new LoginPage();
loginPage.usernameField().type('testuser');
loginPage.passwordField().type('password');
loginPage.loginButton().click();

This approach ensures Cypress waits for elements to be available before performing actions.

Let me add something here and explain 1 more thing...

Option 2 - Cleaner and better - Performing an action inside the function

class LoginPage {
  usernameField() {
    //Works without return:
    cy.get('#username').type("123");
  }
}

So, would you use return or not?

Use return when:

you need to perform multiple actions in a test (.type(), .clear(), .should(), etc.).
you want to chain commands later.

Don't use return when:

The function directly executes an action inside it (like .type("123")).

Just compare the next two rows and look which is better and cleaner for your test scripts.

// Option 1:
loginPage.usernameField().clear().type("testuser")

// Option 2:
loginPage.enterUsername("testuser")

Comparison: getters vs functions in Cypress

When can getters work in Cypress?

If you are migrating from Selenium or (for some reason) from Playwright you might still want to use getters. Then you must return a function inside the getter. However, this adds unnecessary complexity.

Your POM:

class LoginPage {
  get usernameField() {
    //This will work but unnecessary complexity:
    return () => cy.get('#username'); 
  }
}

Your test:

loginPage.usernameField().type('testuser');

While this technically works, using functions directly is a cleaner solution.

Conclusion

Avoid getters in Cypress POMs because Cypress commands don’t return immediate elements.
Use functions to ensure Cypress properly executes commands and handles automatic waiting.
By switching from getters to functions, you’ll write cleaner, more maintainable Cypress tests that follow its execution model.

Have you ever faced issues with getters in Cypress or you think it still better than using functions? Drop your thoughts in the comments below!

Check out more about chaining on official Cypress portal

Cypress assertions. What to use: cy.should() or expect()?

Daniil — Fri, 07 Feb 2025 20:06:23 +0000

Intro

Before we talked about aliases and storing values in hybrid web automation frameworks. Now, let's touch another topic and understand in what cases we should use Chai assertions should() and expect().

In Cypress, you have two main ways to perform assertions:

Cypress built-in assertions

cy.wrap($element).should('be.visible')

Chai assertions

expect($element).to.be.visible

Each method has its own advantages and drawbacks. Let’s break them down.

Cypress assertions

cy.wrap($element).should('be.visible')

Pros:

Automatic retries: Cypress will keep retrying the assertion until the element meets the expected condition or the test times out.
Better handling of asynchronous behavior: Since Cypress is designed to work with asynchronous operations, should() ensures the assertion runs only when the element is available.
Chainable: You can chain Cypress commands with .should() directly, making your code more readable.
Works well with Cypress commands: Since Cypress commands are asynchronous, using .should() ensures that Cypress waits for the command to complete before making assertions.

Cons:

More verbose: Requires wrapping elements with cy.wrap(), which can make the code slightly longer.
Slightly different debugging: Since Cypress retries automatically, it might not immediately fail, making debugging take a bit longer.

Example Usage:

cy.get('.button').should('be.visible');
cy.wrap($element).should('be.visible');

Chai assertions

expect($element).to.be.visible

Pros:

Simple and direct: Less code needed, making it more concise.
Works well with synchronous operations: If you already have a reference to an element and don’t need Cypress’s automatic retries, expect() works well.

Cons:

No automatic retry: If the element isn’t immediately visible, the assertion fails instantly instead of waiting for it to appear.
Doesn’t work well with Cypress commands: Since Cypress commands are asynchronous, trying to use expect() directly on a Cypress command might lead to timing issues.
Less reliable in UI tests: Since UI elements might take time to appear due to animations, rendering delays, or network requests, lack of retries can lead to flaky tests.

Example Usage:

cy.get('.button').then(($btn) => {
  expect($btn).to.be.visible; // Fails instantly if not visible
});

Which one is better?

Use cy.should() as the default assertion method in Cypress tests because:

Cypress automatically retries the assertion.
It works seamlessly with Cypress’s asynchronous nature.
It reduces flaky tests by waiting for the condition to be met.

When to use expect():

If you’re asserting a pure JavaScript object instead of a Cypress-wrapped element.
When checking values inside a .then() block (e.g., API responses, calculations, etc.).

Example of correct expect() usage:

cy.request('/api/users/1').then((response) => {
  expect(response.status).to.eq(200);
});

Best practice: Stick to one for consistency

For better code consistency, maintainability, and readability, use Cypress assertions .should() in most cases.
However, allow expect() only when dealing with non-Cypress elements (e.g., API responses, custom JavaScript objects).

Final Recommendation

Use cy.should() for UI-related assertions.
Use expect() only for non-Cypress elements (API responses, variables).
Don’t mix both styles for the same purpose to keep the framework clean and maintainable.

P.S.

I have used the same approach in my working web automation hybrid framework and it works so well and performance increased.🚀

Efficient way to store values in Cypress: Aliases vs cy.task

Daniil — Sun, 02 Feb 2025 10:39:25 +0000

You may saw that in web automation frameworks we are using either Cypress aliases or cy.task for storing values.
What is the difference between cy.task("saveItem", value) and Cypress aliases cy.wrap().as()?
It is a good question and it has pretty good baseline.
The efficiency of saving an item in Cypress depends on the context of how you plan to use the saved values.
Let’s compare the two approaches:

Using cy.task("saveItem", value)

Best for: Persistent storage or cross-test sharing

This method is used when you need to store data outside of Cypress's test execution environment, such as in a database, a file, or memory storage managed by the Node.js backend.

It enables cross-test persistence, meaning the saved value can be accessed across different test runs.

Example:

Cypress.Commands.add("saveItem", (value) => {
  cy.task("saveItem", value);
});

it("Saves and retrieves data", () => {
  cy.saveItem("myValue");
});

Using aliases cy.wrap(value).as("aliasName")

Best for: Short-term, in-test storage

Aliases are used within the same test or in before/beforeEach hooks but cannot be shared across test cases.

Data stored in an alias is accessible via this.aliasName in function callbacks or with cy.get("@aliasName").

Example:

it("Saves item using alias", function () {
  cy.wrap("myValue").as("savedItem");
  cy.get("@savedItem").then((item) => {
    expect(item).to.equal("myValue");
  });
});

Which is more efficient?

If you need to store values across multiple tests or persist them beyond Cypress's in-memory execution, cy.task() is more efficient.
If you only need to temporarily store data within a single test execution, aliases are more efficient because they are simpler and do not require interaction with the Node.js process.

Recommendation

Use aliases cy.wrap().as() for temporary, within-test storage.
Use cy.task("saveItem", value) when data persistence beyond a single test execution is required.

Let me know your approach to store values in Cypress! 🚀

Beyond Cypress `cy.intercept`: real-time SignalR websocket payments testing in Cypress hybrid frameworks

Daniil — Sun, 02 Feb 2025 08:45:40 +0000

In the first part of this article, we explored the limitations of cy.intercept for WebSocket testing and introduced a Cypress hybrid framework for handling real-time WebSocket interactions. Now, let’s dive into real-world payment testing scenarios, where WebSockets play a vital role in ensuring accurate transaction updates, live balance tracking, and seamless user experiences.

Why WebSockets does matter for payment testing?

Built-in payment systems in a web applications frequently rely on real-time updates to provide users with immediate feedback on their transactions. Unlike traditional HTTP polling, which repeatedly requests data from the server, WebSockets enable instant push notifications, making them ideal for:

Live transaction status updates (e.g., "Payment Processing", "Payment Successful", "Payment Failed").
Real-time balance updates after deposits, withdrawals, or refunds.
Instant fraud alerts and security notifications.

Since Cypress doesn’t natively support WebSocket testing, we need to extend its capabilities using custom commands and WebSocket event listeners. This section will walk through specific payment testing scenarios, including:

Validating real-time payment status updates.
Ensuring balance updates after transactions.
Handling error cases, disconnections, and retries.

Real-time SignalR connection for balance and payment status updates

The connectWStoListen is a custom Cypress command is designed to establish a real-time WebSocket connection using SignalR. It listens for updates related to balance changes and payment status in applications that rely on WebSockets for instant transaction validation.

Cypress.Commands.add(
  "connectWStoListen",
  (url, { onBalanceUpdate, onPaymentStatusUpdate }) => {
    return new Promise((resolve, reject) => {
      const ws = new WebSocket(url);
      Cypress.env("currentWebSocket", ws); // Store WebSocket instance globally
...

Introducing the handshake data

To establish a SignalR connection, we first send a handshake request to the server. This ensures that both client and server agree on communication protocols before exchanging actual data. The format is commonly used across the different types of a web sockets:

...     
      const handshakeData = '{"protocol":"json","version":1}\x1e';
      let receivedEmptyResponse = false; // Track server's empty {} response
      let readyToListen = false; // Track when we're ready to listen for custom messages
...

The \x1e at the end of handshakeData is a special SignalR delimiter, marking the end of the message.

Once the handshake is complete, we can start listening for messages and handling errors.

Handling WebSocket messages & errors

Once the connection is established, the SignalR receives real-time messages from the server. Our Cypress command processes these messages and handles different server responses.

ws.onopen = () => {
        console.log("SignalR WebSocket connection established");
        ws.send(handshakeData); // Step 1: Send handshake message

        ws.onmessage = (event) => {
          const rawMessage = event.data;
          const messages = rawMessage.split("\x1e").filter((m) => m);

          messages.forEach((message) => {
            try {
              const parsedMessage = JSON.parse(message);

              // Step 2: Check for initial empty response {}
              if (
                Object.keys(parsedMessage).length === 0 &&
                !receivedEmptyResponse
              ) {
                console.log("Received empty response {} from server.");
                receivedEmptyResponse = true;
                ws.send('{"type":6}\x1e'); // Step 3: Send type after  empty server response
              }
              // Step 4: Wait for server to respond with {"type":6}
              else if (
                parsedMessage.type === 6 &&
                receivedEmptyResponse &&
                !readyToListen
              ) {
                console.log(
                  "Received server confirmation type 6. Ready for further messages.",
                );
                readyToListen = true;
                resolve(); // Signal that we're ready for payment deposit request
              }
              // Only listen for custom messages 
              // ReceivePaymentStatusUpdate and ReceiveBalanceUpdate
              // after setup is complete
              if (
                readyToListen &&
                parsedMessage.type === 1 &&
                parsedMessage.target
              ) {
                if (
                  parsedMessage.target === "ReceivePaymentStatusUpdate" &&
                  onPaymentStatusUpdate
                ) {
                  onPaymentStatusUpdate(parsedMessage.arguments[0]);
                }
                if (
                  parsedMessage.target === "ReceiveBalanceUpdate" &&
                  onBalanceUpdate
                ) {
                  onBalanceUpdate(parsedMessage.arguments[0]);
                }
              }
            } catch (error) {
              console.error("Failed to parse SignalR message:", error);
            }
          });
        };
        ws.onerror = (error) => {
          console.log(WebSocket error: ${error.message});
          reject(error);
        };
        ws.onclose = () => {
          console.log("SignalR WebSocket connection closed");
        };
      };
    });
  },
);

Error Handling: The WebSocket gracefully logs errors and closes connections to prevent resource leaks.

Automatic Retrying: If pending transactions remain unresolved, Cypress will retry until confirmation is received.

Implementing WebSocket balance verification

Now that our WebSocket connection is in place, we can create a dedicated method to validate real-time balance updates.

connectWStoVerifyBalance() {
      // Construct your WebSocket SignalR URL
      // The URL is based on configuration for specific testing 
      // environment
      const urlWS = `${envConfig.webSocketAPI}${bearerToken}`;
      cy.connectWStoListen(urlWS, {
        onPaymentStatusUpdate: (paymentStatus) => {
          const parsedStatus = JSON.parse(paymentStatus);
          // Wait and retry if payment status is still 'pending'
          if (parsedStatus.status === "pending") {
            console.warn("Payment status is pending. Retrying...");
          }
          // Do an assertion that status is updated to Success
          expect(parsedStatus.status).to.equal("success");
          console.log("Payment status updated successfully:", parsedStatus);
        },
        onBalanceUpdate: (updatedBalance) => {
          // Do required assertions for a balance update
          // Save new balance value if it is necessary
          console.log("Balance updated successfully:", updatedBalance);
          // Close WebSocket connection
          const ws = Cypress.env("currentWebSocket");
          if (ws) ws.close();
        },
      });
    });
  }

Using WebSockets in a Cypress test case

Now, let’s implement WebSocket validation in a Cypress test case to verify that payments are processed correctly and that balance updates happen in real time.

describe("Deposit Feature - Real-Time WebSocket Validation", () => {

  it(`Verify that a user can deposit min amount and payment is successful`, () => {
    // Step 1: User Registration & Setup
    cy.registerNewUser();
    cy.confirmUserIsRegistered();

    // Step 2: Establish WebSocket Connection for Balance Monitoring
    // using our created method
    cy.connectWStoVerifyBalance();

    // Step 3: Navigate to payments and do required actions to
    // initiate a deposit transaction
    cy.navigateToPayments();
    cy.accessDepositTab();
    cy.verifyMinimumDepositAmount();
    cy.validatePendingPaymentStatus();

    // Step 4: Simulate payment process via API/webhook/UI
    cy.updateDepositStatusViaAPI();

    // Step 5: Verify successful payment update on UI
    cy.validateSuccessfulPaymentMessage();
  });
});

Since we've added console logs to our Cypress custom command connectWStoListen, we will see real-time status updates in the Cypress console. This provides full visibility into how SignalR WebSocket connections handle transaction updates.

Conclusion

WebSockets provide real-time transaction tracking for modern payment systems, ensuring that users get immediate feedback. By extending Cypress with custom WebSocket commands, we can:

Test instant balance updates.
Validate payment processing workflows.
Ensure seamless, real-time UX in financial apps.

Would you like to know more about Cypress and QA insights? Follow me on LinkedIn🚀 or subscribe to my TG channel🚀

DEV Community: Daniil

How to handle drag and drop with Cypress in Workflow Builder

Native browser events

Cypress-real-events plugin

Real-world example: connecting nodes on a canvas.

cy.prompt() Changes UI Testing Forever. How it works under the hood

The Pain We’ve All Felt

The Breakthrough - cy.prompt()

Shadow DOM & Slotted Elements Example

🥒 Works with Gherkin & Cucumber

Quick Comparison

Current Limitations

🥷 Shadow DOM in Test Automation: A Practical Guide with Cypress

What is Shadow DOM?

Types of Shadow DOM

Normal DOM (baseline)

Shadow DOM (open)

Shadow DOM (closed)

Slotted Elements

Why Shadow DOM Matters in Automation

Why your Telegram bot test is failing silently

Parallelizing Cypress Tests in CI/CD with Jenkins, Docker, and K8s

TL;DR

🔧 Tools Used

Project structure

Step 1: Cypress setup with parallelization

Step 2: Create a Dockerfile

Step 3: Create a Jenkinsfile

Step 4: Define a Kubernetes Job

Step 4a: How to securely pass CI_BUILD_ID and CYPRESS_RECORD_KEY

Step 4b: 🚀 How Kubernetes runs multiple pods for parallel tests

Step 5: Managing memory & resource allocation

Final Thoughts

Getters vs. functions in Cypress: The best practice you need to know

Cypress works differently from Selenium & Playwright

Why getters fail in Cypress

The correct approach: use functions instead

Comparison: getters vs functions in Cypress

When can getters work in Cypress?

Conclusion

Cypress assertions. What to use: cy.should() or expect()?

Intro

Cypress assertions

Chai assertions

Which one is better?

Best practice: Stick to one for consistency

Final Recommendation

Efficient way to store values in Cypress: Aliases vs cy.task

Using cy.task("saveItem", value)

Using aliases cy.wrap(value).as("aliasName")

Which is more efficient?

Recommendation

Beyond Cypress `cy.intercept`: real-time SignalR websocket payments testing in Cypress hybrid frameworks

Why WebSockets does matter for payment testing?

Real-time SignalR connection for balance and payment status updates

Implementing WebSocket balance verification

Using WebSockets in a Cypress test case

Conclusion

The Breakthrough - `cy.prompt()`