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:
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
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
css or even
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/