Having designed the driver and utility classes for the framework, it is time to talk about the AUT, and how to build the page object classes. We will also introduce industry best practices and standards for topics like naming conventions, folder names and structures, comments, exception handling, JavaDoc, base and subclasses, and so on.

As we spoke about earlier, the framework will follow the Selenium Page Object Model. The premise of this paradigm is that for each browser or mobile page of the application being tested, there is an object class created that defines all the elements on that specific page. It doesn't necessarily know about the other pages in the applications, except for the common methods inherited from its base class. And it doesn't know anything about the test classes that will test the page.

In essence, an abstract layer is built between the page object classes and the test classes. What does that actually mean? Let's take an application page as an example.

If we want to build a page object class for the Google Mail Sign In page, how would we design it, and how would we test it? We would first create a class called something like GmailPO.java (PO for page object), which would store the page element locators that define each control on the page, the methods that allow the user to log in, change password, or test the credentials, and any getter/setter methods required to retrieve a WebElement on the page.

Then, a test class would be created, called something like GmailTest.java (Test for test class), which would contain setup/teardown methods, data provider calls, TestNG annotations, and a test method that would instantiate the GmailPO.java class and call the required methods to test it. The data would be retrieved from the DataProvider-based JSON file, and passed into the class methods. So, in this example, the GmailPO.java class knows nothing about the test class, or any data required to test the page, and the test class knows nothing about the page element locators.