TLDR; Q: what is the best Page Object framework? A: I don’t know. I don’t use any
Question: What is the best Page Object framework for Java? And are there any tools to build Page Objects e.g. scan the page and create a class with all the @FindBy annotations on WebElements etc.
Answer:
I do not use any Page Object Frameworks
I don’t know. I have not researched any Page Object frameworks. I don’t use any, and don’t recommend any.
I know there are plenty of libraries for other languages
Ruby:
- https://github.com/cheezy/page-object
- https://github.com/hammernight/taza
- https://github.com/natritmeyer/site_prism
Python:
And there are bound to be more. I don’t know.
I prefer to:
- write the classes I need by hand,
- as I need them,
- adding methods and
WebElements as I use them - refactoring the classes as they, and my understanding, and our use of them, evolve
I don’t even recommend using the Page Factory built in to Selenium WebDriver e.g. @FindBy’s etc. because every time I’ve used it, I have eventually moved away from those annotations and the PageFactory.initElements to allow more flexible synchronisation and more flexibility in general.
But note the “every time I’ve used it”. Because…
I almost built a tool to create Page Objects
There was a time when I did want a framework to make it easy.
And there was a time where I not only wanted a tool to scan the page and build a class, but I actually thought about building a tool which would scan the page and build the class, and I think I created some prototype code, but I can’t find it now.
But that was when I viewed writing the Page Objects as drudge work. Work that added no value to the automating.
In fact…. Every class we add has a reason.
The classes represent a model of my understanding of the application and how we would go about automating it.
I think being aware of that allows me to build cleaner and simpler code.
Automatically building Page Objects would have led to ’large’ Page Objects which would be unmaintainable.
They would also be hard to use. Imagine code completion on an automatically created Page Object, there would be no grouping of elements into headers and footers, or identified widgets, there would just be a big list of stuff - and would the automatically generated names read well enough to explain what they were for?
I can understand why such a tool or framework would look attractive, but longer term I think it would hamper, rather than improve, productivity.
It ignore the concept of logical domains which overlay the physical world.
And the more that we model logical domains. The more we learn to treat our code as a modelling activity. The more we can create maintainable and robust code.
Experimenting is important
It might even prevent you from experimenting.
In the Page Objects and Beyond talk, I show code which has many different approaches to abstraction for Page Objects:
- Element abstractions
- Physical abstractions (which are analogous to automatically generated abstractions but with full human control)
- Logical Abstractions
- Slow Loadable Abstractions
- Navigation Abstractions
Frameworks as a last resort
I have a general aversion to frameworks.
I don’t mind libraries, but anything that controls the way I write the code, I try to minimize my exposure to.
Because I’ve learned to value flexibility.
I know the code is going to evolve, because I know my understanding will evolve. And my understanding is encoded into the abstractions I write.
I know the application is going to evolve. And I want my code to adapt gracefully as the application changes.
I know I’m going to refactoring my code, to improve the structure and implementation.
I don’t want anything that might get in the way of my doing that.
It could be that there is a perfect framework out there for me, and because I’m not looking for it, I’ll never find it.
But I haven’t needed it.
PS. Having said all that, if you find one that works well then let me know.
My LinkedIn Learning course on Page Objects and Abstractions has more information on this topic.
