Transcripted Summary
So far, we have seen how to set up the boilerplate Java project into your IDE and import the TestZeus library from Github.
Let's move on to the next section and understand the folder structure for TestZeus, and we'll also explain the TestZeus Maven dependency.
# Understanding the TestZeus Framework
Let's understand the high level framework diagram for the TestZeus project.
As a developer and as a manager, navigating an existing codebase has been one of my worst nightmares.
Acknowledging that pinpoint, we will go slowly and carefully into each of these boxes so that you, my friend, can understand how these components of the TestZeus framework work with each other and contribute to our overall goal of self assessed automation.
Without further ado, let's jump into this.
So first, the pom.xml triggers the testng.xml file, so basically the MAVEN build triggers the TestNG suite.
The TestNG repository of test cases then further triggers the Test class.
This is step two - triggering the Test classes.
In step three, the Test class is the actual Test case that we have automated.
For example, logging in into an application, performing some actions, validations, and then logging out.
The test class extends BaseTest, and the test class also uses PageObject.
The BaseTest uses WebDriverFactory to get a driver instance - this is our Selenium WebDriver - and the BaseTest also uses PageFactory to instantiate the PageObject at runtime.
The PageObjects themselves extend SFPageBase.
SFPageBase is the class where we have the custom wait methods for Salesforce, where we are also getting the locators dynamically based on the responses from UI API and the SFPageBase extends PageBase class, which has a standard methods for web interactions.
We will look at all of these in detail in the upcoming chapters.
In addition to the boxes numbered over here, you also have other classes such as the EmailUtils, or the HTTPClientWrapper to perform nuanced actions like interacting with emails or sending and receiving REST API calls.
Now that we have a conceptual understanding of the components of the TestZeus framework, let's try to correlate it back to the code that we have just downloaded from GitHub.
Here on the Eclipse IDE, I have pom.xml open for your reference.
Within the pom.xml file, as you can see, we have the reference to the all-tests-chrome.xml file.
This is the TestNG file from our earlier slide.
When we go inside that file under the resources folder, it highlights the two Test Classes that we want to run using TestNG.
One is AccountCreationViaUI, and the other is AccountCreationViaAPIs.
Let's take a closer look at one of them - AccountCreationViaUI.
This is the actual Test Class for creating an account via the UI of Salesforce.
It has the methods for logging in, passing in the form values, and then logging out.
As you can see, this Test class extends BaseTest.
The BaseTest class has key methods for @BeforeTest, @AfterTest, @BeforeClass, @AfterClass, or suite annotations for TestNG, handling the failures, and other key methods and functions for every test class.
In addition to the BaseTest, we also saw earlier that the actual Test Class uses PageObjects.
One of the PageObjects that we're using is the AccountListPage.
The AccountListPage has the methods for clicking buttons like "New" or "SaveEdit" on the list page.
This follows the standard Selenium PageObject Design pattern.
As you can see, the only change we have done over here is that the AccountListPage extends the SFPageBase.
This is coming from the TestZeus-Maven dependency.
If we take a closer look at the SFPageBase, this is where a lot of the magic happens for automating Salesforce UIs.
We have custom methods for waits.
We also have methods to scrape the UI API and generate dynamic locators on the fly.
We will take a closer look at how all of this is done in our coming chapters. Thank you.
# Using the TestZeus Maven Dependency
For folks who would like to use the TestZeus Maven Dependency instead of utilizing the boilerplate Java framework already present or cloned from the GitHub repo, they can add the TestZeus Maven Dependency in the pom.xml file, and the latest build URLs can be found on testzeus.com.
TestZeus will need two things for successful integration into your existing framework.
One is a WebDriver instance to perform the UI interactions from the SFPageBase class.
And two, the user and API credentials to perform CRUD operations and fetch the UI API details for building the web elements on the fly.
This can be configured by the HTTP client request method present in the framework, and examples can be found on testzeus.com as well.
