Mastering Cypress Testing with Salesforce – Part 1: Essential Setup and Configuration

What is Salesforce Testing and Why is it Unique?

Salesforce is a powerful CRM platform, but testing its workflows can be frustrating—especially for teams adopting Cypress for end-to-end testing. Unlike simple web apps, Salesforce pages are heavy, often slow to load, and use complex DOM structures. Beginners quickly hit timeouts, broken selectors, and disappearing test runners.

Salesforce testing involves verifying the functionality and integrity of your Salesforce customizations, integrations, and business processes. This can include:

• UI/UX Testing: Ensuring the user interface works as expected in Salesforce Lightning or Classic.
• Business Process Validation: Confirming that your custom workflows, approvals, and automations (e.g., in a Sales Cloud or Service Cloud implementation) run correctly.
• Integration Testing: Checking that data is correctly passed between Salesforce and external systems (like a payment gateway or an ERP).
• Security Testing: Verifying that user permissions and data access are correctly enforced.

The key challenge with Salesforce is that it's a "low-code/no-code" platform built on a complex, pre-existing UI framework. This means standard testing practices often fail. Instead of simple HTML IDs and classes, you'll encounter dynamically generated IDs, nested iframes, and a large number of components, all of which require a specialized approach.

This post kicks off our 4-part series “Mastering Cypress Testing with Salesforce,” where we’ll solve the most common Cypress + Salesforce challenges.

In Part 1, we’ll walk through:

• Setting up Cypress for Salesforce
• Configuring timeouts and project settings
• Installing helpful plugins
• Running your first Salesforce test
• Avoiding common setup pitfalls

By the end, you’ll have a working Cypress environment tailored for Salesforce and ready to expand in the next posts.

Step 1: Install Cypress

First, create a project (or use an existing Salesforce repo) and install Cypress:

npm install cypress --save-dev

Open Cypress for the first time:

npx cypress open

A Quick Note on npx: If you're new to the command line, npx is a package runner that lets you execute an npm package command without having to install it globally. It's the recommended way to open Cypress and will automatically create the default project structure for you, including the cypress/ folder and cypress.config.js file.

Step 2: Configure Cypress for Salesforce

Salesforce pages often take longer to load than normal web apps. Let’s update the default configuration to be more resilient to these factors.

In cypress.config.js:

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

module.exports = defineConfig({
  e2e: {
    baseUrl: "https://your-instance.salesforce.com", // change this
    defaultCommandTimeout: 15000, // waits up to 15s for elements
    pageLoadTimeout: 60000, // Salesforce pages can be heavy
    viewportWidth: 1280,
    viewportHeight: 800,
  },
});

🔑 Why this matters:

• defaultCommandTimeout: Prevents flaky failures when Salesforce elements load slowly, giving Cypress more time to find and interact with them.
• pageLoadTimeout: Avoids failures on page transitions, especially on initial visits or redirects.
• viewportWidth/Height: Ensures UI elements render like a real desktop user, preventing layout-based failures and ensuring all elements are in view.

Step 3: Install Helpful Plugins

While Cypress works out of the box, Salesforce testing is smoother with some plugins that add specific commands.

npm install -D cypress-xpath cypress-plugin-tab cypress-wait-until

Why import them here? This file is a great place to extend Cypress's behavior because it's loaded before all of your test files. It's the standard way to add custom commands or third-party plugins.

require('cypress-xpath');
require('cypress-plugin-tab');
require('cypress-wait-until');

🔧 Why these plugins?

• cypress-xpath: Salesforce UI often uses complex, nested DOM structures where CSS selectors are unreliable. XPath provides a powerful alternative for finding these deep elements.
• cypress-plugin-tab: Simulates keyboard tab navigation, which is a common and reliable way to move through forms and fields in Salesforce.
• cypress-wait-until: Helps when waiting for dynamic components, like a spinner disappearing or a specific value appearing after an async operation.

Step 4: Write Your First Salesforce Test

Let’s verify our setup by loading the Salesforce login page. Create a new test file at cypress/e2e/salesforce_setup.cy.js:

describe('Salesforce Setup Test', () => {
  it('Opens the Salesforce login page', () => {
    cy.visit('/');
    cy.title().should('include', 'Login | Salesforce');
  });
});

Run it with the Cypress Test Runner or via the command line:

npx cypress run

✅ If it passes, Cypress is correctly configured for Salesforce.

Step 5: Common Setup Pitfalls (and Fixes)

Selector Best Practices: Avoid using IDs or class names that look like id="j_id0:j_id55". Salesforce often auto-generates these, making them brittle and subject to change. Prioritize stable selectors like attributes or, as a last resort, cypress-xpath to create resilient tests.

Wrapping Up

In this post, we:

• Installed and configured Cypress for Salesforce.
• Increased timeouts to handle slow pages.
• Added plugins for better Salesforce support.
• Ran our first working Salesforce test.

You’re now ready to handle real Salesforce login flows and multi-domain navigation—which is exactly what I’ll cover in Part 2: Cross-Origin and Multi-Domain Challenges.