Comparing Selenium Page Objects with the Selenium API

Comparing Selenium Page Objects with the Selenium API

I have reviewed the Selenium Page Object Model and determined it is no better than the Germanium API in terms of abstracting away low-level locator actions like finding and clicking elements. POM provides no improvement to simplifying the locator strings for the Selenium strategies it uses: xpath, css. One slight advantage for page objects is the unified organization of class structure for multiple page web apps that it suggests you do, plus some standardized methods for page load and fluent waits. With Germanium API you can do the same test actions and get the same test coverage of the Webapp Under Test (WUT aka AUT aka SUT) as with Selenium POM.

With a POM implementation, you wind up with a lot of Java objects floating around in Java code. You have to be good at reading a bunch of code in order to follow the test logic. And, of course, that code needs to be well-written, compiled, tested, debugged. The round trip test development time is thus appreciably large. With the Germanium API you reduce test implementation and maintenance time quite a bit because: . You have the choice of using Python (no compilation before running) . Germanium offers the Abstract Selector class concept flexibility . Germanium has its set of built-in functions for actions on Web elements . These functions come with filtering methods based on the DOM and on element Position relations . The resulting test is far more compact, readable, and maintainable . Best of all: a proper Selector extending the Abstract Selector can be called repeatedly to fetch the target Web element. Selenium locators cannot do this (often the element is gone already).

I have concluded that Germanium’s extra useful API functions combined with the built-in filtering options for some of these functions like: * selector.exists(), * child_nodes(), * selector.containing(selector..), * selector.inside(selector..), * selector.outside(selector..), * selector.left_of(other_selector), * selector.right_of(other_selector), * selector.above(other_selector), * selector.below(other_selector).

(Note that selector in ALL the above can be one of: string, an object instance of a class extending AbstractSelector, WebElement, a selector callable, or a list of any of the preceding items).

Furthermore provides sufficient reduction of xpath string lengths (hence: simplification!). Therefore, assuming bug-free operation of the API functions, along with accuracy of the filtering options, the Germanium API allows the best possible capability for constructing minimal xpath (or css or even js) string selectors and the actions that can be performed on Web elements returned by the selectors.

Article Photo taken from Pexels: https://www.pexels.com/photo/1078979/