Salesforce console testing
Salesforce Consoles can be difficult applications to test because of their particular behavior. Provar has developed various features to overcome these complexities without using code.
One characteristic of Consoles is that their behavior is ‘sticky’, that is, when you start a session in the console, it will re-open tabs that you had open in your previous session. Provar will automatically close any existing Console tabs when running a new test case, so that they do not interfere with the new run. You will see this in action when you run a test case.
Another complexity is that Console applications contain multiple layers of tabs, each with their own iFrame. Provar handles tab switching automatically so that you only need to define the primary tab and secondary tab where the test steps are being performed.
If you are new to Salesforce Console testing, this video provides a brief overview:
To start testing a Console application, first ensure that your Salesforce Console App is defined in the Salesforce Connect step in the test case. This will ensure the test case is run in the Console App and not a standard Salesforce App, e.g. Sales or Call Center.
Any UI test step which is based on this connection will now have three new fields in its parameters:
- Console Tab Type
- Primary Tab Name
- Secondary Tab Name
These together define the tab in which a test step should be performed. They are explained below.
Console tab types
In testing Console applications, the active tab concept is important because Console applications can have multiple tabs open. Provar will generally assume that the test step should be executed on whatever tab is currently active, but this behavior can be changed if the test requires navigating to a different tab. This is defined in each test step so that Provar can execute the test step on the correct tab.
The Console Tab Type controls whether a test step should be performed on the current tab (i.e. the active tab on which the preceding test step ended), or if the tab needs to be changed.
The tab might need to be changed if, for example, the user needs to move from a Case tab to the parent Account to update some information. In this case, the Console tab type would define this as Existing Tab and also require a primary tab name (and a secondary tab name where applicable). Other options are included for opening a new tab, or moving back to a home tab.
Console tab type has the following options:
Home Tab: A home screen such as Case, Account, etc.
Existing Tab: An existing primary or secondary tab which is already open.
New Tab: Selects the + Tab option and opens a new tab by passing a URL into the field.
Current Tab: The currently active tab.
Primary tabs and secondary tabs
Primary tab and secondary tab fields need to match the names which Salesforce has allocated to the Tabs.
These names are defaulted where possible (e.g. when the Console Tab Type is the Current Tab), but they will need to be defined manually when, for example, the user is navigating back to an existing tab.
Provar will use this name to navigate to the correct tab.
This is how the fields appear in Provar.
Note that, if there is no secondary tab, Secondary Tab Name can be left blank.
It is also possible to pass a variable into the tab name (for example a record ID) instead of entering a static value.
These options can also be entered into Test Builder as you map fields.
They will be defaulted where possible.
Closing console tabs
Console applications have a cached history which means when you log in, certain tabs and objects may already be open. To allow your tests to be reliable it is important that your tests start at a known state. In order to achieve this you can close down all existing tabs using a flag in the Salesforce connection step.
Testing custom console components
Salesforce’s Custom Console Components are a useful feature of the Consoles because they help to display the maximum amount of information on a single console page while saving clicks.
Custom Console Components can be created and added to the Console page layout in various locations.
Mapping these console screen components in Provar is no different from the normal procedure of mapping other elements either on a Standard Salesforce page or Visualforce page.
The following steps show the mapping of one such Console component as an example.
Step 1: Right click on the element that you wish to map on the Console custom component.
Step 2: Provide the information on the Test Builder and click Add & Do.
Once mapped, you should see the following in the test step in Provar Desktop.
Page Type: This should be Console Component followed by the object name to which the component belongs, e.g. Account.
Page Mode: This should be the section on which the action should be performed, e.g. Open Cases.
Page Object: This should be the name of the page object created in the Test Builder which stores the fields mapped from the custom component.
Tab Type: This should be defined according to the rules explained in the Console Tab Types section above.
Then save the test case.
- 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