I'm confronted with a web application which has a front-end that has frames in frames in frames. Regarding automated UI Tests with Selenium and Cucumber, is the Page Object Pattern the right approach to consider when having a website front-end structured like this? If so, what would be a best practice to approach the navigation between the frames (up and down)? If it is not the case, what other pattern should I approach instead?
Yes, Page Objects seem the right direction to encapsulate the frame in frames details from the test.
Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests).
var page = new Page();
var result = page.DoSomeAction();
Now I would put the frame switching in the Page
The first rule of test automation is that there are no hard rules but just recommendations, so don't take the page object model "literally". The concept of page object was there long before the pages were so complex.
Now "Page Object model" just means modularising your web page to reduce automation efforts, improve maintenance efficiency, faster execution, reusability of code etc.
So if a single page has two frames that has lots of componenets in each frame, then make page object for each frame. Then you can easily move around as
You can also split the page according to page sections also like footer, header, categories, etc.
If frames doesn't have much element , then keep it in one single page
. Its all depened on your page structure**
Don't learn "How to do something", learn it and understand it then research on how to make it better. Just use whatever you learned as a starting point and not as a final answer.
Read the documentation of Page object from selenium:
You can design a Page object model, in the most efficient way as your project demands. The only hard rule is about assertions. Note that the reference link itself says guidelines and recommendations and not rules.
There is a lot of flexibility in how the page objects may be designed, but there are a few basic rules for getting the desired maintainability of your test code.
Page objects themselves should never make verifications or assertions. This is part of your test and should always be within the test’s code, never in an page object. The page object will contain the representation of the page, and the services the page provides via methods but no code related to what is being tested should be within the page object.
A page object does not necessarily need to represent an entire page. The Page Object design pattern could be used to represent components on a page. If a page in the AUT has multiple components, it may improve maintainability if there is a separate page object for each component.
Note: The encapsulation is done using cucumber feature file in your framework. And doesn't make sense to encapsulate each and everything when you already have native methods by selenium. Design the POM to make your framework as reusable as possible .
I have always found frames wicked confusing 'cos you view src, see an element but then when you write the finder, unless you take into account the frame you get element not found and are confused.
After experiencing this a few times with ruby-selecium-rspec I got used to having to 'look up the page' for the frame, then use a couple of techniques shown below to search within a frame. Bindings are are for Ruby. P is my page object object (build not shown). Basically a class and methods for page objects.
It's 2022 and I've largely retired Page Objects now from my test automation development.
The original idea: isolate identification of elements and provide a common place for them to be defined.
The problems this led to:
- usability is often not tested directly. The user doesn't "see" the classes and ID's often used. Using visuaL elements and text makes sure that the automation reproduces the actual user experience and ensure it continues to work
- The test code is not self-documenting. Using visual elements as identifiers instead of page objects means there no need to document them separately in page objects with good names. They are already self-documented with good names as part of the UI. This helps pressure better names for all
- duplication of element identification by developers, automaters and designers
- an abstraction that required checking every time there was an issue
- elements moved and only some of the identifiers are updated
All that said, I still use them sparingly, frequently for poorly code HTML elements missing attributes normally used, e.g. images that when click do actions, but this are increasingly rare as the devs use IDs too