Throughout this book, we have dealt with single-page applications, for which we wrote single-file scripts. This approach is the simplest, as illustrated by the following diagram; we write one script (in a single file) for each web page of our application:

This method works fine for a while. But what if we encounter a new scenario for testing the same web page? We have two options. We can continue to use the same script file that we used previously, or we can create a new script file for the new test scenario. Let's examine these two options, as follows.

Option 1: We can add the code for the new test to the old script file. A home page requires two test scenarios, and we can write them both in the same script file, as shown in the following diagram:

However, if we choose the preceding option, the following applies:

• We risk breaking the previous test.
• Maintaining the code will become more difficult, as more lines of code are added.

Option 2: We can create the new test in a new script file. A home page requires two test scenarios, and we can write each one in a separate script file, as follows:

However, if we choose the preceding option, the following applies:

• We will be replicating the code related to the navigation of the web page(locating and interacting with the web elements of the page, for example).
• If changes are made to the web elements of the page in the future, we will have to update both the old and new scripts.
• Suppose that instead of two automation scripts, you have a hundred scripts for a single web page—things will get complicated.

Neither of the preceding options are optimal. The best practice is to utilize an approach similar to the multi-tier architecture in test automation scripts (even for a single-page web application). By applying software development best practices, we can separate the navigation and validation tasks for automation script writing. We can do so through the Page Object Model (POM), as illustrated in the following diagram:

The preceding diagram shows us what the POM consists of and how it changes the way that we design and write automation scripts:

• There is a Page Object class for each web page in the application. The Page Object class includes the code specific to handling the page's web elements, including finding its elements, accessing its attributes, and more.
• There are as many automation scripts as there are scenarios that we might need to test for each web page. Every script will instantiate the page object that is testing and will only handle the methods of the test.

Advantages of POM

Implementing POM into automation script writing can provide the following benefits
to a testing project:

• It separates WebElements navigation code and automation script code, which provides for cleaner and easier-to-understand code.
• It creates a repository of Page Objects, which allows them to be reused for different purposes and testing scenarios.
• If the design or layout of WebElements and/or their attributes are changed, we will only have to modify its corresponding Page Object, not every script that uses it.

You should now understand what the Page Object Model is and how it improves the automation script-writing process.