Page Object, WebdriverIO advanced concepts - components sharing

Page Object pattern is well-known in the world of test automation. Fortunately the new version (v4) of webdriver.io test automation framework was designed with Page Object pattern in mind, so we can fully benefit from this approach. One of advanced concepts of Page Object pattern is components sharing – today we will take a closer look at this.

Background

Some time ago I had a chance to use both of them in practice (webdriver.io and Page Object pattern). My task was to cover medium-size web application with UI tests. I was working on it with second developer and it took us about three months. To organize tests we chose Page Object pattern. At first sight it looked great, but unfortunately we run, in fact really quickly, into following problem – each page had some duplicated logic related to the header, footer, menu, widgets panel etc.

Surprisingly I didn’t find much information about this matter on the Internet. Actually the only one was probably this topic.

Author proposes to use inheritance (to be more specific – multiple inheritance) to deal with duplicated code like headers. Personally I think it is not the best practice. Today I will try to show you another way how to deal with components sharing between page objects and convince you that it is much better than inheritance.

Where is the problem?

As I said in the introduction, problem with duplicated logic occurs when we had to deal with common parts of the page like header, footer, menu, etc.

Let’s take a look at the project containing these two pages:

We can start by defining some isolated elements of each page:

The list of common components is as following:

header

footer

widgets

Create page objects structure and tests

I said that one of the possible solutions is to separate common sections to other page components and use inheritance. Page components – that’s a good idea. Inheritance – I think we can do better, without inheritance.

Why components composition is better than inheritance?

In the world of software development there are many reasons why we should use composition over inheritance. Unfortunately, I don’t think that all of them apply to UI tests where basically the code structure is much simpler than any system architecture. I don’t want to “stretch the truth”, so I’m not going to write about low coupling, maintenance, extendability and things like that in which the composition is much better than inheritance. But! I think there are at least two important things why we should choose composition, so let’s look at them:

1. Name collisions – in case of webdriver.io and UI tests I think this one is the most important one. When we look at site example I’ve shown in this post, you can notice that there are many similar elements. For example sign up button. You can find it in two places – header and jumbotron section. If we would make header a component with one sign-up button and then on home page we would inherit this component, a names collision would happen. Eventually, we would have to change the name of the one sign up button:

For me – this is much better. We’re always in some context – home page, header etc.

2. IDE code completion – second really important thing – IDE code completion. This issue will occur when you decide to use multiple inheritance (probably it would happen quite soon, because with shallow, but large pages structure single inheritance is not enough). To achieve this you will probably use one of the available libraries like xmultiple. Everything works great except one thing – you lose IDE support for code completion. If you are the only one who works with given part of the codebase that may not be a big problem, but when someone else will have to maintain this code, it’s really big difficulty for that person.

Summary

That’s all! I hope I convinced you that you should use components composition. I’ve been using it in my project for many weeks and we managed to cover whole site with webdriver.io UI tests. What’s more – components composition is very flexible, so we were able to restructure our “architecture” few times without any problems.

Want more? Go to my GitHub repository, there you can find whole example site, page objects, components and everything prepared just to download and run!