Using composition over base page class inheritance in PO model test framework

Recently, while refactoring a testing framework (using Webdriverio, JS) to a Page Object model, a question arised if having a base page class that all the other pages would inherit from could be avoided and composition could be used instead.

Is it essential to have the inheritance hierarchy or can we just have a separate pageHelpers module which will contain all the general-purpose functions to interact with the page?


Um, PO = PageObject , okay, I’m not a Java person though. I did a PageObject implementation in Python, and am regretting not making the base class an interface class. That’s probably easier to retrofit in Java, I assume, but why you would want to is the real question. If you are asking the question from a language cleanliness perspective, then it’s probably the wrong question to ask. Test engineers are not the language lawyers that developers are… oh damn

Hey, welcome to the MOT @mariam-sargsyan . sorry where are my manners now? Sorry about that, and hey, brilliant question, I would like to hear from Automation Panda (Andy?) on this topic one day. He did a reptile-name-based tool in .NET, I forget what it was called. Which is a language I find hard to relate to and probably answers this question better than I can. Since .NET has far more in common with Java…but I’m going to give it a shot, and explain 2 things that I’ve yet to fix in my Python implementation.

  1. I still have no clue how I’m going to make my tests “mobile portable”. I want to get this right if possible, and hence I want to keep adhesion as low as possible. It’s too easy to just re-write tests for mobile and desktop, and I want to find a way to merge these 2 without using the existing approaches which frankly feels like design-poisoning.
  2. I’m finding that my base class is now doing 2 things over time, and Python being a lazy language (the language lawyer in me talking.) Currently my base class composes page object interactions, but it also abstracts those messy webdriver interactions in a convenient way.
  3. And, to be honest it probably does a 3rd thing, it’s maintaining a lot of data, not just a reference to the webdriver. Another reason to split into 2 or three objects.

I guess the reason I’m loath to split it is due to not knowing how to achieve my mobile/desktop test portability goal, and because I don’t have terribly much unit testing of this base page-object. Sorry if this is just me moaning about languages, would rather love to hear what your practical concern was though. I’ll stop rambling now, because I really want to hear back before I braindump more, because I am triggering my #mansplaining sensor right now and want you to teach me some Java too Mariam.