(POM) Page Object Model Structure?

I have ever developed a Katalon Studio project for WebUI Automation (not REST API Automation) applying Page Object Model.

Here is a Test case that uses my “Page Objects”:

One of my “page object” is here for example

This “Page Object” has a line

	static final By APP_HEADER      = By.xpath('//h1[contains(text(),"Flaskr")]')

Here I use org.openqa.selenium.By class to make a query for a tex “Flaskr” in the target HTML.

You can imagine, you want to use JMESPath instead of By. Then your “REST-Response Object Model” would be ready to verify JSON input.

By the way,
You would find that the structure of this project is unusual as a Katalon Studio project. The Test Case flaskr/TC3_Alice_and_Bob_interact is short; it uses no Test Object. It uses very little of WebUI.* keywords. There are many codes in the Include/scripts/groovy folder that implement methods to read data out of HTML and perform verifications. This project has such unusual structure because the “Page Object Model” does not fit in a Katalon Studio project very well.

The POM is really a design pattern for Object-oriented programming (OOP). Katalon Studio is not designed with OOP in mind. Katalon Studio is good for non-programmers. It’s main features (Test Objects, Test Case, Built-in Keywords) are designed to be friendly for the programming-beginners. But these features rather disturb the programming-experts who want to use OOP design patterns including POM.

@manik.tandon

You wrote you want to apply POM to your project. Then you must be a real programer. You would find it easier to apply POM in a usual Java/Groovy project with Selenium WebDriver & Apache HTTP Client on Gradle/Maven/Ant, than in Katalon Studio.

Finally, let me explain what is the very reason why I think Katalon Studio and POM does not fit. Katalon Studio does not help you to do unit-testing for the classes you wrote. If you are to use Page Object Model, then you will write many "class"es in Groovy or Java. If you are to write “classes”, you would need to write and execute JUnit tests intensively. Katalon Studio does not help you to do JUnit-based tests at all. Katalon Studio intentionally hides Eclipse’ JUnit support (once I tried to restore it by my custom keyword ). Why they did so? I guess that Katalon thought that it is better to hide the name “JUnit” from the users perspective in KS for simplicity. And they thought that all codes you write (or generated by the Recorder tool) in a KS project with Built-in Keywords & Test Objects will be easy to debug; you would not want unit-tests on your codes. This assumption is valid if you are a programming beginner who don’t know what the “class” keyword is. But a seasoned OOP programmer will find that it is difficult to develop a fair scale of class library in Katalon Studio. In short, you are not supposed to do any OOP in Katalon Studio.

In fact, I developed my “POM” class library for the sample project above in another Gradle-backed project. There I did enough JUnit-based testing. And once completed, I copied the Java source code of my POM into a Katalon Studio project to reuse it.