EPOM

One of the reasons that record/playback tools are not popular is that they usually produce tests that are hard to maintain and therefore hard to escalate. In the previous sections, we have showcased the benefits of keeping the code in separate sections and ideally, we would like these tools to do so for us. However, even if the tools were to produce code in such a way, having screenshots and different object locators would revert the system to not being scalable.

We can enhance a POM to include screenshots and create automation that runs over the record/playback tools to create maintainable and scalable code, reducing the effort of writing repetitive lines. This will also work for other types of application-related elements:

Figure 5.5: Example of design of EPOM

For the following code example, we are going to use Python. The reason for this is that we will be using a library that allows you to find objects using a screenshot (the Airtest project...