Salesforce Console Testing
Salesforce Consoles can be difficult applications to test because of their particular behavior. Automation has developed various features to overcome these complexities without using code.
One characteristic of Consoles is that their behavior is ‘sticky’; when you start a session in the console, it will re-open tabs that you had opened in your previous session. Automation will automatically close any existing Console tabs when running a new test case so 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 its own iFrame. Automation handles tab switching automatically, so you only need to define the primary and secondary tabs where the test steps are performed.
Setup
To start testing a Console application, ensure 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 that 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 active tab, 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 an Existing Tab and require a primary tab name (and a secondary tab name where applicable). Other options include opening a new tab or returning to a home tab.
The 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 that is already open.
New Tab: Select the + Tab option and open a new tab by passing a URL into the field.
Current Tab: The currently active tab.
Primary tabs and secondary tabs
Primary and secondary tab fields must match Salesforce’s names 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 Automation.
Note that the Secondary Tab Name can be left blank if no secondary tab exists.
Passing a variable into the tab name (for example, a record ID) is also possible 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, meaning certain tabs and objects may already be open when logging in. To allow your tests to be reliable, your tests must start at a known state. You can close down all existing tabs using a flag in the Salesforce connection step to achieve this.
Testing custom console components
Salesforce’s Custom Console Components are a valuable 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 added to the Console page layout in various locations.
Mapping these console screen components in Automation differs from mapping other elements on a Standard Salesforce or Visualforce page.
The following steps show mapping one such Console component as an example.
Step 1: Right-click on the element 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 Automation.
Screen Type: For a Visualforce page, This should be Salesforce Visualforce Page.
Page: This should be the section on which the action should be performed, e.g., Product Selector.
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.
For more information, check out this course on University of Provar.