Added Standard Page Objects

[qytera-development]

Added Standard Page Objects

[csvtuda]

I'm not a reviewer here, but I would like to point out a few things for your consideration.

Assertions

I don't think moving assertions into the page objects is going to make your life easier. You'll sooner or later be faced with assertions that cannot be easily built with the ones you've added. For example, how are users going to assert that:

• A button becomes enabled when hovering it?
• A links does not have a href attribute?
• An element is visible for three seconds, disappears for five and then becomes green?

Probably through first retrieving the raw SelenideElement using element() and by then writing the assertions outside of the element's class themselves. So why bother with the elements' assertions at all? Writing:

assertEquals(element().getText(), "hello");

is not that much longer compared to:

element.assertInnerTextEquals("hello");

Rigid page objects

All QTAF elements can be clicked, which is good. But:

• Only buttons have a method isEnabled. Why can't users check whether an input is enabled?
• Users can send keys to a FormElement. Why can't they send a key to a button, such as Enter?
• A DateTextElement's content can immediately be retrieved as some Java date object. Why can't users retrieve a FormSelectElement's options as a date objects, e.g. for logging applications where a date can be selected from a dropdown?

Well, they can. By first retrieving the raw SelenideElement using element() and by then writing the interactions themselves using said Selenide element. Or by writing the method for retrieving the String and converting it into a date object themselves.

These page objects are way too rigid in my opinion. And some feel very arbitrary, like the NumberElement for Double only. Where's the Integer parsing? And with text and numbers covered, do we also need an ImageElement? There will be a lot of confusion for QTAF users when raw Selenide elements are scattered across the application, only because QTAF's elements do not offer the required flexibility.

There's a reason that more or less all HTML-based UI testing frameworks only provide a single type of Element, be it WebElement in plain Selenium, SelenideElement in Selenide, Locator in Playwright or even Cypress with its subject chains. Applications aren't homogeneous enough to divide them into less than ten page objects. And adding more page objects would just lead to greater maintenance and design efforts, both from QTAF developers and QTAF users. Do I need a FormElement or a FormInputElement? What happens if a ButtonElement needs to become a FormElement? Do all tests need to adapted?

---

All in all I think what bothers me is the following. If:

• unwrapping the element offers more flexibility/makes the users' life easier
• users won't be able to cover their entire application using QTAF elements

Why should they bother sticking to QTAF elements?