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?

  • 1
    Page Object is usually the best approach unless you're just doing something quick and dirty (like a short-term screen-scraper). I do recommend taking a look at Geb as an excellent DSL for Selenium, including Page Object. Commented Apr 3, 2020 at 4:06

4 Answers 4


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 DoSomeNavigation and DoSomeAction methods.

  • I get the approach that you showed with your example and the way I was building up my test scenario was already going in this direction. Would you dedicate each frame that you need to interact with (and whose elements are important for your test) an own page object though?
    – Mh_tm92
    Commented Apr 3, 2020 at 8:06
  • 1
    No, I would keep the pageObject interface user focus, the user does not know and doesnt care about the frames. Maybe in the pageObject you create and use a frameObject to increase readability in the pageObject. Also in a later stage the developers might remove the frames, but the user interaction probably stays the same. Commented Apr 3, 2020 at 10:01

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 .

  • That would not hide the UI structure from the tests, or do you use these frameObjects in other pageObjects? Commented Apr 2, 2020 at 9:50
  • @NielsvanReijmersdal why you have to hide the UI structure? and How do you access the elements in the frame for the approach you suggested?
    – PDHide
    Commented Apr 2, 2020 at 9:54
  • That is sort of the idea behind page objects. They have action methods describing functional actions the user can take on the page. Read martinfowler.com/bliki/PageObject.html Commented Apr 2, 2020 at 10:04
  • @NielsvanReijmersdal THe below is a good reference : selenium.dev/documentation/en/guidelines_and_recommendations/… read the paragraph that says PAge object is flexible and the only hard rule is not to use assertion
    – PDHide
    Commented Apr 2, 2020 at 10:38
  • Please comment something when someone downvotes
    – PDHide
    Commented Apr 2, 2020 at 10:39

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.

enter image description here

enter image description here


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.