Environment Management
Environment management is an important feature which avoids storing environment-specific details within your Automation test cases. This allows you to change environment without needing to update your test cases. Environments can be used with all types of Connection, including Salesforce, Database, Web Service, Email and Non-SFDC UI testing Connections.
Salesforce environment management
By default, Automation builds and runs test in a single specific Salesforce org, accessed via user details defined in the Connection.
However it is often useful to run the same Automation tests in multiple different Salesforce environments. Depending on your organization, you may want to create and run Test Cases in a Dev sandbox, and then run the same tests against your Full sandbox and again on Production after deployment.
Using Automation’s Environments feature, you can run your tests in additional environments without adding additional Connections.
Note: A specific test environment can also be defined when running Automation via ANT. This is done by referencing the test environment in the Runner Task of the Build.xml file.
What is an Environment in Provar?
In Provar, an Environment provides a way of varying information on the Connection while inheriting the other Connection details. It is often used to store different Salesforce Environment details, such as sandboxes, which can reuse the same Connection details with only minor modifications. This helps increase reuse and reduce maintenance effort. Environments can also be used for toggling between the Classic and Lightning UIs, since this setting is stored at the Connection level.
A Salesforce Connection is a user in Salesforce. It is always important to select your users carefully to ensure they have the correct profile for your testing. In addition, when you are using Environment Management, you should first make sure that this logical user is available in all your environments. If you choose a business user for this testing there is a risk that may leave the company and so be disabled after the next sandbox refresh. For this reason you may want to consider adding users into production which will then be copied back to all environments for your testing.
Environment Variables
Environments can also be used together with Environment Variables. These are values which are set by the Environment currently in use, but which can be referenced from a test case (for example with an If statement). This is useful if you need to apply different logic in the test case based on the Salesforce environment in which it is being run.
A good example of using an environment variable is for inbound email testing (email to case). The email address you need to specify will change depending upon the org you are testing against. Using an Environment Variable you can reference this in your tests, instead of a hardcoded value.
Setting up environments
Before setting up environments, first decide how many environments you want to set up. You should set up one environment for each org in which you want to run your test cases. The only exception is your default org, which will not need to be set up as an environment. Your default org should be the first org where you start authoring your test cases.
To add a new environment, navigate to the Test Settings view and select the Environments tab. Click the + button to create a new test environment.
Supply an Environment Name and Description. This should generally be the name of your sandbox, e.g. Dev. (If you want to use environments to toggle between the Classic and Lightning UIs, refer to the Lightning Testing module for detailed steps.)
Then click the OK button.
Navigate to the Connections tab in test settings. To add a new connection at this point, click the New (+) icon in the top-right. Alternatively, if you have already added your connections, click on your chosen Connection and click the Edit icon in the top-right.
Once on the connection edit screen, add the new connection information if needed, then click the + button in the Overrides section.
Select the environment created earlier, then provide the user details for the new test environment.
Note: If user details are not provided against the environment, Automation will use the default user details against the connection when you select this test environment.
Repeat these steps as needed if you are adding multiple new environments.
To run tests in the new test environment, select this environment in the Test Environment dropdown in the menubar of Automation.
As mentioned above, Automation’s environments feature has applications beyond simply managing user details of different sandboxes. Refer to the Salesforce Lightning Testing page for another example of how environments can be used to run test cases in both Classic and Lightning UI and drive different environment-specific behavior in the test.
- Provar Automation
- System Requirements
- Browser and Driver Recommendations
- Installing Provar Automation
- Updating Provar Automation
- Licensing Provar
- Granting Org Permissions to Provar Automation
- Optimizing Org and Connection Metadata Processing in Provar
- Using Provar Automation
- Understanding Provar’s Use of AI Service for Test Automation
- Provar Automation
- Creating a New Test Project
- Import Test Project from a File
- Import Test Project from a Remote Repository
- Import Test Project from Local Repository
- Commit a Local Test Project to Source Control
- API Testing
- Behavior-Driven Development
- Consolidating Multiple Test Execution Reports
- Creating Test Cases
- Custom Table Mapping
- Functions
- Debugging Tests
- Defining a Namespace Prefix on a Connection
- Defining Proxy Settings
- Environment Management
- Exporting Test Cases into a PDF
- Exporting Test Projects
- Japanese Language Support
- Override Auto-Retry for Test Step
- Customize Browser Driver Location
- Mapping and Executing the Lightning Article Editor in Provar
- Managing Test Steps
- Namespace Org Testing
- NitroX
- Provar Test Builder
- ProvarDX
- Refresh and Recompile
- Reintroduction of CLI License Check
- Reload Org Cache
- Reporting
- Running Tests
- Searching Provar with Find Usages
- Secrets Management and Encryption
- Setup and Teardown Test Cases
- Tags and Service Level Agreements (SLAs)
- Test Cycles
- Test Data Generation
- Test Plans
- Testing Browser Options
- Tooltip Testing
- Using the Test Palette
- Using Custom APIs
- Callable Tests
- Data-Driven Testing
- Page Objects
- Block Locator Strategies
- Introduction to XPaths
- Creating an XPath
- JavaScript Locator Support
- Label Locator Strategies
- Maintaining Page Objects
- Mapping Non-Salesforce fields
- Page Object Operations
- ProvarX™
- Refresh and Reselect Field Locators in Test Builder
- Using Java Method Annotations for Custom Objects
- Applications Testing
- Provar Manager
- How to Use Provar Manager
- Provar Manager Setup
- Provar Manager Integrations
- Release Management
- Test Management
- Test Operations
- Provar Manager and Provar Automation
- Setting Up a Connection to Provar Manager
- Object Mapping Between Automation and Manager
- How to Upload Test Plans, Test Plan Folders, Test Plan Instances, and Test Cases
- Provar Manager Filters
- Uploading Callable Test Cases in Provar Manager
- Uploading Test Steps in Provar Manager
- How to Know if a File in Automation is Linked in Test Manager
- Test Execution Reporting
- Metadata Coverage with Manager
- Provar Grid
- DevOps
- Introduction to Provar DevOps
- Introduction to Test Scheduling
- Apache Ant
- Configuration for Sending Emails via the Automation Command Line Interface
- Continuous Integration
- AutoRABIT Salesforce DevOps in Provar Test
- Azure DevOps
- Running a Provar CI Task in Azure DevOps Pipelines
- Configuring the Automation secrets password in Microsoft Azure Pipelines
- Parallel Execution in Microsoft Azure Pipelines using Multiple build.xml Files
- Parallel Execution in Microsoft Azure Pipelines using Targets
- Parallel execution in Microsoft Azure Pipelines using Test Plans
- Bitbucket Pipelines
- CircleCI
- Copado
- Docker
- Flosum
- Gearset
- GitHub Actions
- Integrating GitHub Actions CI to Run Automation CI Task
- Remote Trigger in GitHub Actions
- Parameterization using Environment Variables in GitHub Actions
- Parallel Execution in GitHub Actions using Multiple build.xml Files
- Parallel Execution in GitHub Actions using Targets
- Parallel Execution in GitHub Actions using Test Plan
- Parallel Execution in GitHub Actions using Job Matrix
- GitLab Continuous Integration
- Travis CI
- Jenkins
- Execution Environment Security Configuration
- Provar Jenkins Plugin
- Parallel Execution
- Running Provar on Linux
- Reporting
- Salesforce DX
- Git
- Version Control
- Salesforce Testing
- Recommended Practices
- Salesforce Connection Best Practices
- Improve Your Metadata Performance
- Java 21 Upgrade
- Testing Best Practices
- Automation Planning
- Supported Testing Phases
- Provar Naming Standards
- Test Case Design
- Create records via API
- Avoid using static values
- Abort Unused Test Sessions/Runs
- Avoid Metadata performance issues
- Increase auto-retry waits for steps using a global variable
- Create different page objects for different pages
- The Best Ways to Change Callable Test Case Locations
- Working with the .testProject file and .secrets file
- Best practices for the .provarCaches folder
- Best practices for .pageObject files
- Troubleshooting
- How to Use Keytool Command for Importing Certificates
- Installing Provar After Upgrading to macOS Catalina
- Browsers
- Configurations and Permissions
- Connections
- DevOps
- Error Messages
- Provar Manager 3.0 Install Error Resolution
- Provar Manager Test Case Upload Resolution
- Administrator has Blocked Access to Client
- JavascriptException: Javascript Error
- macOS Big Sur Upgrade
- Resolving Failed to Create ChromeDriver Error
- Resolving Jenkins License Missing Error
- Resolving Metadata Timeout Errors
- Test Execution Fails – Firefox Not Installed
- Selenium 4 Upgrade
- Licensing, Installation and Firewalls
- Memory
- Test Builder and Test Cases
- Release Notes