Salesforce testing
Salesforce test automation
Salesforce changes underneath your tests three times a year, and Lightning's DOM changes far more often than that. Klarent writes Salesforce tests that survive both.
The Salesforce testing problem
Why traditional automation struggles with Salesforce
A dynamic DOM
Lightning generates dynamic, deeply nested markup with unstable identifiers, so selectors that pass today fail tomorrow.
Asynchronous loading
Components load asynchronously, so scripted tests act before the page is ready and fail for no real reason.
IDs that keep changing
Selector-based tools depend on IDs that customisation and managed package updates change without warning.
Releases on Salesforce's schedule
Three seasonal releases a year force a full regression testing pass on Salesforce timeline, not yours.
Maintenance outpaces coverage
Every layout change, new field and package upgrade means more script repair, and less time for new tests.
Admins cannot automate
Salesforce admins know the processes best, but Selenium suites need engineers to write and maintain them.
How it works
How Klarent tests Salesforce
Step 1 - Describe
Describe the process the way an end user would perform it, in plain English.
Step 2 - Build
The AI agent builds the executable test from the live page, without hand-built selectors.
Step 3 - Run
Run against a sandbox on every change and every seasonal release.
Platform capabilities
Salesforce test automation that survives change
No dependence on generated markup
Elements are identified from what is on the page, not from Lightning's generated IDs and class names.
Self-healing tests
When customisation, a package update or a seasonal release changes the UI, self-healing repairs the affected steps.
Async, iframes and modals
Handles asynchronous loading, iframes and modal layers, so tests wait for the page instead of racing it.
Cross-system journeys
Test processes where Salesforce is one step, not the whole process, together with your other web apps.
Authored by admins
Admins and business users write tests in plain English. Engineering reviews and approves them.
Evidence on every run
Executed steps with screenshots, plus Playwright traces with console and network logs, for every run.
What you can test
What you can test in Salesforce
Lead, opportunity and case lifecycles
From lead capture to closed opportunity, and from new case to resolution.
Quotes and approvals
Quote and approval workflows, including validation rules.
Custom objects and components
Custom objects, custom fields and Lightning Web Components.
Profiles and permission sets
What each user type can see and do, across profiles and permission sets.
Managed packages
Managed package behaviour after an upgrade.
Automation outcomes
The results of Flows and other automation, checked through the records they change.
Surviving the seasonal release cycle
Spring, Summer and Winter, without the scramble
What typically breaks
Seasonal releases change Lightning components, page layouts and default behaviours, which breaks scripted tests even when your processes still work.
Test the preview sandbox first
Run a targeted pass against a preview sandbox before the release reaches production, while there is still time to act.
Let self-healing absorb UI changes
Steps broken by moved or renamed elements are repaired, so the suite keeps running through the release.
Evidence for sign-off
Every run in the release cycle leaves evidence your team can review before go-live.
Fits your Salesforce DevOps process
Automated Salesforce testing in your pipeline
CI triggers and sandbox targeting
Trigger runs from GitHub, GitLab, Jenkins or Azure DevOps, and point the same tests at any sandbox by overriding the URL.
Deployment gating
Failed critical tests block the deployment and report the issue.
Results into Jira and Slack
Failures reach the tools your team already works in.
Integrations
Fits into your existing stack
Connect to GitHub, Jira, Slack, and more - no reconfiguring your workflow.
Automate one Salesforce process against your sandbox.
Pick a process like lead to opportunity or quote approval, and see Klarent build, run and self-heal it against your own sandbox.
FAQs
Lightning generates dynamic, deeply nested markup with identifiers that change between page loads, releases and customisations. Selenium tests depend on those selectors, so they break constantly, and asynchronous loading makes them act before the page is ready.
Klarent tests through the browser, the way a user does, so it needs a user login for the org or sandbox you want to test. Credentials are stored as secrets, encrypted at rest and masked in logs and screenshots.
Yes. Custom objects, custom fields and Lightning Web Components are tested through the UI like any other part of the org, without hand-built selectors.
Salesforce ships three seasonal releases a year: Spring, Summer and Winter. Run your suite against a preview sandbox before the release reaches production. Where the release changes the UI, self-healing repairs the affected steps so the suite keeps running.
Yes. Admins and business users describe processes in plain English, and the AI agent builds the executable test. Engineering reviews and approves tests before they join the suite.
Yes. A single test can follow a process from Salesforce into an ERP, a billing system or a custom web app, so the whole journey is tested the way it actually runs.
Yes. Point tests at any sandbox by setting or overriding the URL, so the same suite can run against a developer sandbox, a preview sandbox or production.
Klarent tests through the user interface. Apex logic is covered by the behaviour it produces in the UI, such as records created, fields updated or validation errors shown, while Apex unit tests stay part of your Salesforce development process.