30 posts tagged with "Test Automation"

Every Salesforce team tests. The question is how — and what slips through the cracks depending on which approach you use.

In this post, I'm going to take a real Salesforce application — Dreamhouse, Salesforce's official sample app — and test the same functionality three different ways:

1. Apex unit tests (the traditional Salesforce-native approach)
2. Selenium WebDriver (the industry-standard UI automation approach)
3. DevAssure O2 Agent (autonomous browser-based testing)

For each approach, I'll show you the actual code, explain what it catches, what it misses, and the ongoing maintenance cost. By the end, you'll have a clear picture of where each approach fits — and where it falls short.

For years, I led teams focused on engineering productivity and release management across startups and enterprises. My primary job was not just shipping features — it was ensuring release trains moved predictably, developers remained productive, and quality gates did not become velocity killers.

One thing became very clear over time:

Engineering velocity was rarely limited by coding speed. It was limited by testing friction.

You merged on Friday. Checkout looked fine in the diff. By Monday, support tickets say promo codes stop applying after a failed payment retry.

The PR was 400 lines, mostly written by Cursor in an afternoon. Two approvals. Green CI — because unit tests passed and nobody had an E2E check for that path.

Every team wants E2E tests on every PR. Almost none actually has them — because someone has to write those tests, fix them when the UI changes, and defend a thirty-minute CI job that still flakes.

If you are the developer opening the PR, that someone is often you, after hours, clicking re-run on a red check you do not trust.

Your team already plans and tracks tests in TestRail. The gap is execution: turning those cases into reliable UI automation without a second script suite to maintain. DevAssure closes that loop—fetch cases from TestRail, run them in a real browser with an AI agent, and optionally sync results, defects, and videos back to TestRail.

Every TestRail workflow in this guide is available in two places: the @devassure/cli for terminals and CI/CD, and the DevAssure VS Code extension (VSCE) for interactive runs from the IDE. Configure once—credentials and post-result settings are shared between both.