Environment management is an important feature which avoids storing environment-specific details within your Provar 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, Provar 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 Provar 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 Provar’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 Provar 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.
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, Provar 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 Provar Desktop.
As mentioned above, Provar’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.
- General information
- Licensing Provar
- Provar trial guide and extensions
- Using Provar
- API testing
- Behavior-driven development
- Creating and importing projects
- Creating test cases
- Custom table mapping
- Debugging tests
- Defining a namespace prefix on a connection
- Defining proxy settings
- Environment management
- Exporting test cases into a PDF
- Exporting test projects
- Managing test steps
- Namespace org testing
- Provar desktop
- Provar Test Builder
- Refresh and Recompile
- Reload Org Cache
- 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 plans
- Testing browser options
- Tooltip testing
- Using the Test Palette
- Test Palette introduction
- Control test steps
- List compare
- Read test step
- String test steps
- UI Test Steps
- Using custom APIs
- Callable tests
- Data-driven testing
- Page objects
- Block locator strategies
- Introduction to XPaths
- Creating an XPath
- Label locator strategies
- Maintaining page objects
- Mapping non-Salesforce fields
- Page object operations
- Refresh and reselect field locators in Test Builder
- Using Java method annotations for custom objects
- Applications testing
- Database testing
- Document testing
- Email testing
- Mobile testing
- OrchestraCMS Testing
- Salesforce CPQ testing
- ServiceMax testing
- Skuid testing
- Vlocity testing
- Webservices testing
- Introduction to test scheduling
- Apache Ant
- Configuration for sending emails via the Provar Command Line Interface (CLI)
- Continuous integration
- Azure DevOps
- Running a Provar CI task in Azure DevOps
- Configuring the Provar 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
- GitHub Actions
- Running a Provar CI task in GitHub Actions
- 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 CI
- Travis CI
- Parallel Execution
- Running Provar on Linux
- Salesforce DX
- Team foundation server
- Version control
- Zephyr Cloud and Server
- Salesforce testing
- Adding a Salesforce connection
- Assert Page Error Messages on Add/Edit Product
- Dynamic Forms
- Internationalization support
- List and table testing
- Salesforce Release Updates
- Salesforce Lightning Testing
- Salesforce Lightning Web Component (LWC) locator support
- Salesforce console testing
- Visualforce Testing
- Testing best practices
- Configurations and permissions
- Error messages
- Licensing, installation and firewalls
- Test Builder and test cases
- Release notes