Page Object Model: Base Page necessary?

Question

I've gone back and forth on this, and am sort of having a hard time deciding if a "Base page" class is necessary or a good idea.

In most cases this base page class someone stores common functions (or sometimes common locators like headers/footers) and a lot of time these are abstract classes with abstract methods that all child page classes should have (Such as a goto/navigate method all page objects may have or similar "action" methods).

However, I have also seen others argue that we should prefer composition over inheritance: https://stackoverflow.com/questions/49002/prefer-composition-over-inheritance which means we should use utility classes or classes that hold action methods and then use components to pull into our other PoM classes (In the case of a common component such as a header/footer)

I've conflicted in whether a base class really ever has a place for PoM? Personally i've only ever housed methods such as a goto method that all PoM sub-classes SHOULD have but even that's probably not 100% necessary.

What are the benefits to one way over the other, and if there is a base class what should be in it?

Answer 1

The answer will be in your domain.

An inheritance relationship is a "is" relationship, whereas a composition relationship is a "has" relationship. The first talks about what makes necessarily nature of that object; the second talks about what occasionally makes that object.

E.g. Let's say that this license information is mandatory by law to exist in every page.

But let's say that the exact placement/format/content is free to choose.

In this case, an abstract function called getLincenseText would exist in a base class for all pages. But each page could implement it differently.

If the placement/format/content must be one throughout all pages, this function would be a concrete function.

The same can be said for functions such as navigateTo or getURL.

On the other hand, the search bar obviously can exist or not in any page. In this case, you would have a class called SearchBar which exposes functions of related to searching.

In each page that needs to have a search bar, you can then create an object of type SearchBar, passing to its constructor how to find the bar on that particular page.

However, it doesn't mean that can't have an abstraction for pages with a search bar that are in the same place.

For instance, you can have an abstract class called SearchablePageWithBarOnTop, which has the location showed before, with the search bar as a component. Then the QuestionPage and UserViewPage can inherent from this class, since they are searchable pages with a bar on top.

Answer 2

I used to think like you, my thought process was that adding a base page was over engineering a simple process but when you have a Base page well structure it will give your test the same structure.

From the base page you can get the header, sidebar, content, and footer and from there you can start implementing your own pages within the same context. Because in current times most of the websites have contents that loads in the same page instead of navigating to other sections of the site.

If you have a website with a lot of functionalities you will find out that the "content" will change a lot instead of the actual website, is not like goTo, because you are not navigating to anywhere is more about getting.

For summary I would go without a base page for pretty basic applications or if I'm testing something new in a prototype but if the application is work related a base page is a must.