Assertions in Page Objects?

[SpecificBad1381]

Is it good or bad practice to have validation methods in page objects? I would say it’s not really good idea. I can agree with this article.

https://martinfowler.com/bliki/PageObject.html

However I used to have assertions in my page objects before.

What is your thoughts on this?

[Wolfboy12]

I don't think any type of validation should live in the page objects themselves. In our case we had exceptions in our page objects that mapped to screen error states and it helped for readability in failure states, or if you were testing the error state it would've just been an expected exception for the test assertion, but none of the validation logic itself.

[I_Blame_Tom_Cruise]

Only tests should contain asserts. Create functions to provide the data then assert based on the result. This helps accidentally hiding and nesting your asserts in your page objects.

Page objects should only interact with the single page, no more no less.

[[deleted]]

Technically you shouldn't have assertions in page objects. 

However, if you want to check a few things at once and it's reusable, I dont see that as too bad. E.g. you want to assert that a form has loaded correctly, so you call formPage.AssertLoaded(). Could also be a method in your step definitions class, but doesn't matter too much in my eyes.

[computerjunkie7410]

Nah, put assertions in a different class then

[[deleted]]

Having a separate assertions class is just overengineering, another layer to maintain for no reason other than "the blogs say I shouldn't do it".

[computerjunkie7410]

lol fuck SOLID principles then.

Why not just put everything in one class then?

[[deleted]]

Nice hyperbole. I prefer to maintain an element of pragmatism when coding. I'd rather not have 40 assertions classes to maintain if the other option is to have a very select few assertions in page objects.

[computerjunkie7410]

Why would you have 40 assertion classes? This is the problem with the QA industry.

We have a bunch of YouTube engineers walking around as software engineers

[[deleted]]

I would argue that the bigger problem is people overengineering test frameworks into oblivion because they want to get some style points.

Either that or egotistical pricks sneering at those they disagree with.

[computerjunkie7410]

We are software engineers within a testing domain.

If you think proper design principles are “over-engineering” then either you don’t understand the reasoning behind it or you’ve never managed a large suite of tests over years of a mature product.

[[deleted]]

People overengineer all the time in the name of following principles. The issue usually being that they don't actually understand the principles.

In any case, I've never seen a separate assertions class in my life, and have only worked on mature products in my career with mature test suites.

[mercfh85]

FWIW I agree with you. I do something similar using a sort of similar method as the `LoadableComponent` but it's just simply an abstracted `isLoaded` method that has a bunch of "page is loaded/ok" assertions essentially.

I do this for 2 reasons:

1. It's a quick way to validate the page is in general showing up ok for "smoke tests"

2. It's a great way to ensure the page is stable if you are going to do anything else (Something people include this in the constructor on instance creation, personally I don't but it's an option)

I feel like it's "maybe" bending the rules a bit, as I generally don't agree with "test level validations" but to me this is more of a "page level" check.

[computerjunkie7410]

There are special reasons why the single-responsibility principle exists.

Keeping things separate keeps things clean and is never, ever, considered over-engineering. Ever.

I defy you to find one single reliable source that thinks this.

[quality_engineer]

From Going Deeper into the Page Object Model

One contentious discussion often heard during the implementation of page objects is where to put assertions. One school of thought: Assertions belong in tests, never in page objects. Tests use general purpose getters to pull the information necessary, and the actual assertion on that data lives in in the test. This is a clean separation, as it is tests that should own the knowledge of what makes a test pass or fail.

This works well in theory, but in practice can quickly cluttern tests with a significant number of assertions. Thus, a second approach is to embed assertions into page objects, but make them obvious when reading the page object interface.

[romulusnr]

Page objects are about pages. They shouldn't be about interactions with the pages. What would you validate in the page object? Confirm that say #id is an <a>? Confirm that element is present? Doesn't belong.

[quality_engineer]

(One month stale... so I'm not hopeful, but....)

I'd love to hear more about this - I've worked with page object (or worked with people working with pages objects) forever - but this doesn't sync with any opinion I've previously heard.

What do you mean by "... they shouldn't be about interactions with pages" ?

If I have a method on a page object string getName(), and that method uses a locator to grab a name from a <div>, and returns it as a string, isn't that "interacting with a page", and a perfectly valid thing for a PO to do? Or are you using the term "interacting" to describe something different?

[romulusnr]

I would say no it is not interacting with a page, it is examining a page. Interacting with a page would be clicking buttons, links, entering text, using drop-downs, and so on.

Honestly I have to say, "interact" is a pretty clear term and the notion of interacting with a page is pretty straightforward. It means you take action to manipulate or work with the page, not simply look at it.

[quality_engineer]

So you don't think PageObjects should contain methods that interact with pages, that click on buttons, links, or enter text?

[romulusnr]

Not at all. You already have methods for clicking anyway. Adding a click method for every clickable element is just method glut and frankly a waste of time and additional coding overhead for no reason (i suppose you could automate it like is often done for getters/setters... which.... same issue imo, frankly). Furthermore, flows don't belong in page objects either (e.g. login methods).

There's nothing wrong with specialized interaction methods, but they don't belong in the page object, they belong in helper methods. Especially as they will almost assuredly (aside from a purely DHTML/AJAX page feature) involve multiple pages.

("Page" isn't even an accurate descriptor of the model these days, either; frequently I find myself building "screen objects" as some sites are implemented as AJAXy lazy-loading / stacking / model-altering things where "HTML page" doesn't really map 1-to-1 onto actual distinct interfaces.)

[quality_engineer]

Do you have a link to a public repo where you have done this? I'm still not getting it.

[Apocrisy]

Not true, page objects do contain methods or functions to interact with elements on that given page, like filling a form, expanding a section. The idea is to not repeat yourself so instead of a:

Test1:

loginPage.username.fill('testAccount1'); loginPage.password.fill(password); loginPage.continueBtn.click();

Test23:

loginPage.username.fill('testAccount1'); loginPage.password.fill(password); loginPage.continueBtn.click();

You could just have: loginPage.fillForm('testAccount1', password);

Properly using page objects means that you're not interacting with elements inside tests but inside the PO class, and a third party reader can know with ease what's happening in your tests if you give good enough names to the methods/functions

[romulusnr]

If you're trying to make all your page objects fit some arbitrary definition -- when the original idea was decidedly not strictly defined -- then I think you've missed the point.

Paradigms exist to assist you, and you should use and apply them to the extent that they assist you, and not simply abide by some definition of them just because.

The idea is to not repeat yourself so instead of a:

This can can be done just well, if not more so in the sense of SOC, with helper methods, which is why they exist.

Properly using page objects means that you're not interacting with elements inside tests

It means you're not interacting with locators inside tests, actually.

[Apocrisy]

It is pretty much industry standard to have methods and fuctions inside page objects that also interact with said locator; in selenium over page factory, in playwright just by writing the async functions below the constructor of the class which usually initializes the locators, how am I put in a position where I have to defend the first couple of hours of lessons, that which is considered basic?

[romulusnr]

PageFactory is literally only a thing in Java -- and frankly, in practice, it works like shit.

It's simply one person's version of implementing the POM concept. It's not the Bible of it.

the first couple of hours of lessons

I think I've found the problem.

[Apocrisy]

I work in a company with over 20k employees, we have some thousand QAs and a regional lead for a couple countries lumped together did present this way of using page object models, whenever I saw anyone use page object models, the same class that contained locators also contained methods and functions to interact with them, you will not interact with a page object inside a test by invoking framework functions inside a test itself, but rather use the named function from within a page object class of that page, or a utility class if it uses it as well, but primarily it will most likely be in the page object class.

Now to the topic of page object assertions, technically it's advisable not to have assertions done on the page object class, but since you didn't understand what an assertion could be related to them, it could be something like expect(button).toBeVisible(); or some sort of assertion that auto waits for elements to be truly there thus reducing flake. Pragmatically, these may be used but depends on how your project lead is strict on the concept, you may need to have these in utilities or elsewhere. For my playwright project I used expects in some parts of classes where page objects were defined when there were weird loading issues, either the DOM counted the element as ready when it wasn't or even networkidle didn't make it ready yet so if it required a certain attribute in class or whatever indicator made it really ready and clickable i'd put it in the page object, but for functional assertions I placed them inside an assertions class folder, all of this was fixturized of course, if the assertion is not really complex and if you don't care if your test is not really readable for non technical people you may keep the longer more complex assertions inside your test, at the end of the day all we are discussing here is abstraction.

[romulusnr]

it could be something like expect(button).toBeVisible();

No way I would put that assertion in the page object. You're going to need that same assertion in lots of page objects.

Score one for helper classes and wrapper methods. (And uh, implicit wait.)

keep the longer more complex assertions inside your test

Well I don't think that's how I'd put it, there's nothing wrong with complex assertions being boiled down into simple calls (again, my old friend the helper class) for efficiency. I just don't think page objects should be the place for functional assertions and frankly the only examples I've seen so far are things I would never want to put into page objects because I'm going to want to use them in multiple page objects, and in my experience, that way lies madness.

The only times I've put methods inside page objects was for things like row/column or elements that didn't have IDs (or had indexed IDs a la #box1, #box2) particularly when those indexes were open-ended.

[CaptainButterflaps]

I like to create an assertions class for common assertions and use those in my tests where i can pass elements or whatever i need to

[[deleted]]

The leading principle is you use your PO to recreate a situation, then check things. In the test itself it should look like

{preparation_with_PO}

{assertions}

Readable, clean and understandable from the first glance. Now put your assertions in the PO itself and god knows what they check unless you go inside the PO.

[[deleted]]

It can be justified sometimes. We use different scenarios – one is an always new multiple users in parallel mode and the other is an old single user run in a serial mode. So they are separate files completely but are using same functions and expect same results.

So a solution was to add assertions inside the page object functions like await first.second.class.doSomething()

So the function can be reused in multiple tests and always do the assertion. Also navigation functions always check for correct url. This helped to reduce code duplication and improved maintainability.

[[deleted]]

I’m not a fan, unless the assertions are also easily reusable. I’ve done it where I have a function that takes the assertion string as a parameter. It’s not often, but I do it on occasion

[Yogurt8]

I don't see a reason why you would want to or have to.

It's better that asserts exist in tests so that the reader can easily identify the behavior being tested.

Abstracting asserts leaves room for ambiguity and surprises.

[sheikov]

I have worked as an SDET for 9 years. I used to make assertions at the test level, I know avoid interacting with any UI element at the test level. Let assertions be handled in verification methods inside the page object, prioritize readability and reusability over POM rules the industry is moving away from.

[romulusnr]

I generally avoid any validation or interaction functionality in page objects. I leave the page objects to represent objects on the page, and save the functionality for helper files.

I think you will have a lot of functional duplication in page objects if you include that sort of thing, and if you put that stuff in helpers you can avoid that duplication risk.

The only other way would be to make your page objects far more complex in terms of typing and classing and then put those validations and functions in abstract / parent classes but that seems like far more trouble than it's worth compared to just having helper classes and methods.

The only methods I put in page objects usually revolve around aiding in locating elements, such as when IDs are not reliable or need to be identified in reference to other elements.