Setup and teardown test cases
The following includes information about how to use setup and teardown test cases.
Setup test cases
Setup test cases are designed to run at the beginning of your test case in order to declare and define conditions and variables. The primary benefit of using a setup test case is to simplify the process of making global changes to test case parameters.
Note: If you have several test cases arranged in a test folder, the setup test case will always execute first.
How to create a setup test case
Step 1: Click the New Test button in the top left portion of your screen.
Step 2: Select Setup Test Case.
Step 3: Choose the option to create a connection. If you need to create a connection, choose the preferred option or select No Connection Required.
Step 4: In the following example, create a test case for an Account Object.
Step 5: Create a setup test case VariableDeclaration-Accounts.setup and specify the variables for all account test cases. For example, AccountName=”TestAcc001″. Once you add variables in the setup test case, make sure to change the Value Scope of the variable as Test Folder/Test Run if you want to use variables in test cases within the same folder of the setup test case.
Step 6: Change the Value Scope to Test Folder/Test Run.
Step 7: Execute the account folder by selecting the folder and clicking Run.
In this scenario, the VariableDeclaration-Accounts.setup test is executed first and subsequent tests leverage the variables defined in the setup test case.
Teardown test case
A teardown test case will execute at the end of your test run within a test folder. Teardown test cases are used to perform post test execution actions. For example, a teardown test case can be used to delete test data generated during test execution.
The following includes instructions for creating a teardown test case.
Step 1: Click on the New Test button within the top left portion of your screen.
Step 2: Select Teardown Test Case.
Step 3: Choose the option to create a connection. If you need a connection, choose the preferred option or select No Connection Required.
In the following example, a teardown test case is created to delete test data that was created during test execution.
Step 4: Create a test case Account Test Data Cleanup.teardown.
Step 5: Add a SOQL step to specify the Object Id with the Account Name created in the setup test case.
Step 6: Add a step to delete the record. You can reference the API testing support article to learn more.
Step 7: Execute the Account folder. You will see that the VariableDeclaration-Accounts.setup test is executed first and that the teardown test case is executed at the end.
- Provar Automation
- Installing Provar Automation
- Updating Provar Automation
- Using Provar Automation
- 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
- Override auto-retry for Test Step
- Managing test steps
- Namespace org testing
- Provar desktop
- Provar Test Builder
- Refresh and Recompile
- Reintroduction of CLI license Check
- 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
- Generate Test Case
- List compare
- Page Object Cleaner
- 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
- Guide in Salesforce CPQ Testing in Provar
- Guide in ServiceMax Testing
- Skuid Testing
- Vlocity API Testing
- Webservices testing
- 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
- Gearset DevOps CI/CD
- 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
- Execution Environment Security Configuration
- Provar Jenkins Plugin
- Parallel Execution
- Running Provar on Linux
- Salesforce DX
- Team Foundation Server
- Version control
- Provar Automation trial guide and extensions
- Salesforce Testing
- Adding a Salesforce connection
- Assert Page Error Messages on Add/Edit Product
- Internationalization support
- List and table testing
- Salesforce Release Updates
- Salesforce Lightning Testing
- Salesforce Lightning Web Component (LWC) locator support
- Salesforce console testing
- Visualforce Testing
- Provar Manager
- Best Practices
- Configurations and permissions
- Error messages
- Licensing, installation and firewalls
- Test Builder and test cases
- Release Notes