Provar

Provar Testing for Salesforce: Setup, Best Practices, and Alternatives

HelpMeTest

HelpMeTest

— 8 min read
Provar Testing for Salesforce: Setup, Best Practices, and Alternatives

Provar is a Salesforce-native test automation tool built specifically to address the most common pain points in Salesforce UI testing: dynamic element IDs, frequent layout changes from seasonal releases, and the complexity of Lightning Web Components. While general-purpose tools like Selenium can be made to work with Salesforce, they require significant custom infrastructure to handle Salesforce's quirks reliably. Provar's Salesforce-specific design eliminates much of that overhead.

This guide covers everything you need to get started with Provar: installation, configuration, building your first test cases, and the metadata-driven approach that makes Provar particularly effective for Salesforce. We also look at when Provar is the right choice versus when alternatives make more sense.

What Is Provar and How Does It Work?

Provar is a desktop-based test automation IDE built on Eclipse. Unlike browser-based test recorders or cloud-hosted platforms, Provar runs on your local machine and connects to your Salesforce org through Salesforce's APIs and WebDriver.

The fundamental insight behind Provar's design is that Salesforce's metadata — field API names, object names, component names — is stable in ways that DOM element IDs are not. A field named Account_Name__c keeps that API name forever, even as Salesforce's rendering engine changes the HTML structure around it across seasonal releases. Provar builds its element locators from Salesforce metadata rather than DOM inspection, which is why Provar tests tend to survive Salesforce upgrades better than comparable Selenium scripts.

The Provar Connection to Salesforce Metadata

When you connect Provar to a Salesforce org, it reads your org's metadata — objects, fields, page layouts, and components. This metadata becomes the foundation for building test steps: instead of inspecting the DOM for a CSS selector, you select "Account: Account Name" from a metadata-driven field picker. Provar then generates the underlying locator based on that metadata.

This approach has two major benefits:

  1. Reduced maintenance: When Salesforce changes the DOM structure in a release, Provar's metadata-aware locators adapt. You don't need to re-record or fix selectors after every update.
  2. Faster authoring: Non-Selenium experts can build tests by selecting fields from a structured UI rather than writing XPath or CSS selectors.

Installation and Setup

Prerequisites

Provar requires:

  • Java JDK 11 or later
  • A Salesforce org (production, sandbox, or scratch org)
  • A Salesforce Connected App configured with OAuth settings
  • Windows or macOS (Provar Desktop does not run on Linux)

Installing Provar Desktop

Download the Provar installer from the Provar website. The installer packages Provar's Eclipse-based IDE, a bundled browser driver, and Provar's Salesforce metadata engine. Run the installer and follow the prompts.

After installation, launch Provar and create a new workspace. The workspace is a directory on your machine where Provar stores your test projects, metadata cache, and configuration files.

Connecting to Your Salesforce Org

  1. In Provar, open Provar Settings → Connections
  2. Click Add Connection
  3. Select your org type (Production, Sandbox, Developer Sandbox, or Scratch Org)
  4. Enter your username and click Refresh Metadata

Provar authenticates using your browser session — it opens a Salesforce login page, you authenticate, and Provar captures the session. For CI/CD environments where interactive login isn't possible, Provar supports OAuth JWT Bearer Flow using a Connected App and private key.

Once connected, Provar downloads your org's metadata and builds its internal model. This initial download takes a few minutes depending on your org's complexity but is cached for subsequent sessions. Refresh metadata when you deploy schema changes.

Provar Project Structure

A Provar project contains:

MyProject/
├── .provar/           # Project configuration
├── page-objects/      # Reusable component definitions
├── tests/             # Test case files (.testcase)
├── data/              # Test data files (Excel, CSV)
└── results/           # Test execution results

Building Test Cases

Creating a New Test Case

Right-click the tests folder and select New → Test Case. The test case editor opens with two panels: a step palette on the left and a step canvas on the right.

Test cases are assembled by dragging step types from the palette onto the canvas. Provar provides steps for:

  • Salesforce steps: Navigate to record, click button, set field value, assert field value
  • Browser steps: Open URL, click element, enter text, take screenshot
  • Data steps: Loop over data rows, read from Excel, parameterize inputs
  • Logic steps: If/else conditions, loops, try/catch error handling

A Practical Test Case: Creating a Contact

Here's a straightforward test case for creating a Contact record and verifying it was saved correctly:

Step 1: Navigate to Contact New Form

  • Step type: Salesforce → Navigate
  • Target: Contact → New Record

Step 2: Set First Name

  • Step type: Salesforce → Set Field Value
  • Object: Contact
  • Field: First Name
  • Value: Test

Step 3: Set Last Name

  • Step type: Salesforce → Set Field Value
  • Object: Contact
  • Field: Last Name
  • Value: ATF Contact ${timestamp} (parameterized to avoid duplicates)

Step 4: Set Account

  • Step type: Salesforce → Set Lookup Value
  • Object: Contact
  • Field: Account Name
  • Search Term: Acme Corporation

Step 5: Save

  • Step type: Salesforce → Click Button
  • Button: Save

Step 6: Assert Name on Detail Page

  • Step type: Salesforce → Assert Field Value
  • Object: Contact
  • Field: Full Name
  • Expected Value: Test ATF Contact ${timestamp}

Step 7: Cleanup

  • Step type: Salesforce → Delete Record
  • Target: Current Record

The metadata-driven field selection (steps 2-4) is where Provar's Salesforce awareness shines. You're selecting Contact: First Name from a structured picker — Provar knows this maps to the firstName field in the Lightning Experience UI and generates the appropriate locator.

Handling Dynamic Content

Salesforce Lightning Experience is JavaScript-heavy, and dynamic content — lookups that trigger async searches, validation rules that fire on field blur, record pages that load sections asynchronously — can make tests flaky if not handled properly.

Provar's Wait Mechanisms

Provar includes built-in wait handling that understands Salesforce's rendering patterns:

Implicit waits: Provar automatically waits for the Lightning framework's spinner to clear before interacting with elements. You don't need to add explicit sleep steps for most standard interactions.

Explicit wait steps: For custom Lightning components with non-standard loading patterns, add a Wait for Element step that pauses until a specific element becomes visible or clickable.

Dynamic lookups: When typing in a lookup field, Salesforce displays a dropdown with search results that load asynchronously. Provar's lookup step handles this by waiting for the dropdown to appear before selecting a result.

Custom Lightning Component Interactions

Standard Salesforce fields and components work out of the box with Provar's metadata-driven steps. Custom Lightning Web Components require manual configuration:

  1. Open Provar's Page Object editor
  2. Add a custom element definition, specifying the CSS selector or XPath for your component's interactive elements
  3. Reference the page object in your test steps

For LWC components with shadow DOM, Provar's browser extension can help identify stable locators within shadow roots — a common challenge with Salesforce custom components.

Test Data Management with Excel

Provar uses Excel spreadsheets as its primary data source for data-driven testing. This makes test data accessible to business analysts and QA engineers who aren't comfortable with JSON or database queries.

Test Data: Contact_Creation_Tests.xlsx
Sheet: ContactData

| FirstName | LastName        | AccountName      | Phone        | ExpectedStatus |
|-----------|-----------------|------------------|--------------|----------------|
| John      | TestUser001     | Acme Corporation | 555-0101     | Active         |
| Jane      | TestUser002     | TechCorp Ltd     | 555-0102     | Active         |
| Invalid   | (no last name)  |                  |              | Error          |

In Provar, create a For Each Row step that iterates over this spreadsheet. Each iteration runs the test with the values from that row. This turns one test case into dozens of test scenarios without duplicating test logic.

Organizing Tests into Test Plans

Provar's Test Plan concept groups related test cases for execution as a regression suite. Test plans can be:

  • Sequential: Test cases run one after another, which is required when tests share state (e.g., a record created in test 1 is referenced in test 2)
  • Parallel: Tests run simultaneously across multiple browser instances, reducing total execution time

For most regression suites, parallel execution is preferred. Provar manages the browser instances and collects results centrally.

Provar in CI/CD Pipelines

Provar includes a command-line runner (provar.sh / provar.bat) and an ANT build configuration that enables headless execution in CI/CD pipelines:

<!-- build.xml for Provar ANT execution -->
<project name="ProvarRegression" default="run-tests">
    <taskdef resource="com/provar/core/testng/antlib.xml"
             classpath="${provar.home}/ant/provar-ant.jar"/>

    <target name="run-tests">
        <provar
            home="${provar.home}"
            projectPath="${basedir}"
            testSuite="SmokeTests"
            resultsPath="${basedir}/results"
            metadataConnection="SandboxCI">
        </provar>
    </target>
</project>

For Jenkins:

pipeline {
    agent any
    stages {
        stage('Provar Regression') {
            steps {
                sh 'ant -f build.xml run-tests'
            }
            post {
                always {
                    publishTestResults testResultsPattern: 'results/**/*.xml'
                }
                failure {
                    mail to: 'qa-team@company.com',
                         subject: "Provar Regression Failed",
                         body: "Build ${BUILD_URL} failed regression"
                }
            }
        }
    }
}

Provar also has a native Salesforce DevOps Center and Copado integration, which surfaces test results within the Salesforce ecosystem if your team uses those platforms.

When Provar Is the Right Choice

Provar is a strong choice when:

Your team is entirely Salesforce-focused. If 100% of your testing work is Salesforce testing, Provar's Salesforce-specific features justify its specialized tooling. The metadata-driven authoring and built-in Lightning wait handling reduce overhead significantly compared to building Salesforce-capable Selenium infrastructure from scratch.

You have frequent seasonal releases. Salesforce's three-year-round releases can break Selenium tests that use fragile DOM selectors. Provar's metadata-based locators handle these releases more gracefully.

Non-technical QA engineers are writing tests. Provar's visual, drag-and-drop interface is more accessible to QA analysts without coding backgrounds than writing Selenium or Playwright scripts.

You need Salesforce-specific assertions. Provar understands Salesforce concepts like record ownership, sharing rules, and profile-based field visibility — validations that are awkward to express in generic Selenium tests.

When to Consider Alternatives

Provar's specialization is also a limitation. Consider alternatives when:

You test both Salesforce and non-Salesforce applications. Provar isn't the right tool for your mobile app, external customer portal, or non-Salesforce web applications. A more general-purpose tool — Playwright, Selenium, or a cloud testing platform — can cover your entire application portfolio.

Your team prefers code-first testing. Provar's IDE-based, visual authoring doesn't suit developers who prefer writing test code in Python or JavaScript. For code-first Salesforce testing, consider a Selenium or Playwright setup with Salesforce-aware helper libraries.

Budget is constrained. Provar's licensing cost is significant for smaller teams. Open-source alternatives combined with Salesforce-specific utilities (like the salesforce-webdriver-utils library) can provide comparable coverage at lower cost.

You need AI-powered test maintenance. Provar's metadata-driven approach reduces maintenance but doesn't eliminate it. For teams that want self-healing tests — tests that automatically adapt when selectors change — platforms like HelpMeTest offer AI-powered self-healing on top of Playwright, which can cover Salesforce alongside the rest of your application stack.

Maintaining Provar Tests Long-Term

The most common Provar maintenance challenge is metadata drift: custom fields get deleted, page layouts change, or new managed packages introduce new required fields. Stay ahead of this with:

Scheduled metadata refreshes: Refresh Provar's metadata cache after every deployment that includes schema changes. Add this as a step in your CI/CD pipeline.

Test ownership: Assign each test plan to a functional owner who's responsible for keeping it current with their area's schema changes.

Deprecation tracking: When a field or component is being removed, identify all tests that reference it and update them before the removal deploys to production. Provar's search functionality can find all usages of a specific field across your test suite.

Version control: Store your Provar project in Git. This lets you compare test changes over time, roll back bad edits, and work collaboratively without overwriting each other's changes.

Provar represents a mature, well-considered approach to Salesforce test automation. For organizations committed to the Salesforce platform with significant testing needs, it reduces the overhead of Selenium-based automation substantially. The key is honest assessment of whether your testing scope extends beyond Salesforce — if it does, a more general-purpose platform may serve you better.

Read more