Should we use page objects?
Nikolay Advolodkin
Founder @ UltimateQA | 150K engineers trained in 184 countries
??My thoughts on Page Objects in test automation
Someone recently asked me what I think of page objects, and I realized it's time for an update.
What makes a suitable page object?
The "page" object was a poorly chosen name as it makes us think that a class can only be an entire HTML page. Not the case. Many page objects can be small components of a page.
This ProductsPage
is composed of a CartComponent
??Here's an entire C# repo that uses page objects for web and mobile
Want to read an in-depth description of the points above, you can read this
?? Do I like the use of page objects for test automation?
Yes, if we are doing a lot of black-box e2e testing. It's not a perfect model. However, it's very simple to pick up for almost anyone. Titus Fortner is a fan of it. And he's amazing at what he does.
领英推荐
However, it has its limitations. I especially don't like how it makes moving from functional e2e to any lower system testing impossible without rewriting the tests.
No, if we can do white-box testing of our apps as well. For example, with the ability to do e2e, component testing, unit testing, and API testing, I'm not 100% sure if we need page objects even for our UI tests. It might be overkill, especially if we don't want to do too much UI testing.
Filip Hric has a similar opinion, as he expresses in his Youtube video
It depends a lot on the app and the control of our environment. However, in this example of a live web application that I coded and hosted, I had only a few e2e UI tests. My tests were component tests, visual tests, front-end performance, and snapshot tests. Hence, do I need extra code and abstractions in the form of page objects for so few e2e UI tests? I lean towards "no".
Furthermore, imagine if I started all of my testing by writing e2e UI tests with page objects. This is actually very common. If I wanted to replace those e2e UI tests with more efficient tests (component, snapshot, visual...), I would need to delete the code I spent time writing. Replace that code with new code. Hence, creating page objects in this case wasted engineering time.
We did have a wonderful conversation about page objects and screenplay pattern with Titus Fortner and Andrew Knight . Listen to that below.
In summary
Page objects are a great start for anyone looking to start better UI automation. They're simple. I like simplicity.
Page objects might be overkill once you start doing testing of the entire system using unit tests, component tests, API tests, UI, and so on. Meaning that you might have so few UI tests that page objects become unnecessary as the value they serve is minimized.
??What do you think about page objects? What other questions do you have about them???
Staff Software Engineer In Test at MercuryGate International
2 年automation is not a cookie cutter activity, both in terms of approach, philosophy, expectations and tooling -- it always "depends" on other factors. Having the understanding and wisdom of when, how, where and why is the key to success.
IT Professional/Servant Leader
2 年Couldn't agree more Nikolay Advolodkin! You have nailed it. I particularly liked that fact that you pointed out that a page object does not need to represent the whole page; I particularly divide a page into different page objects, depending upon the case. Also I am glad that you listed the cases where is makes sense to have page objects and when it doesn't. Spot on!!!
Lead Software Engineer @ Carousell, Core member of TAQELAH
2 年Nikolay Advolodkin: Do you know anyone who uses page object design for unit tests or API tests? I'm very curious!
Lead Software Test Engineer | Software Quality | Test Automation | Co-organizer of taqelah | Maintainer of HowTheyTest and PlayPI
2 年This is the first time I see a mention of pageobjects even considered for non UI tests. Why would anyone think about that in the first place?
Software Engineer | Java | C# | TypeScript
2 年Page Objects/Components belong to a particular layer of testing. Trying to use them in every layer is where the problem begins. :)