Question: We have an android app that we have to do a little bit of usability testing/beta testing.All I have found about Utest.com is you can sign up and work on projects, but I was unable to find how to post projects in Utest and how to get people to do usability testing.

I am fine with other paid options as well, but if it is free or something like usabilityhub where we can do testing and then earn points to exchange for credit, then I am fine.

I am not sure if this is the right place to ask, if not please point me to the right place.

Answer: 
Given that there is disagreement, the answers this question attracts will probably gravitate toward **sometimes** rather than yes/no.

My opinion is that page objects should have assertions in their constructors, so that my code doesn't offer page methods for a page I never reached.

In a made up example, I don't want to return an account page object when I've hit a 404 because I'll eventually hit a NoSuchElementException.

I don't want my debugging journey to begin at:

> 
> Where did this element go / did the selector change?
> 
> 
> 

I want to start at:

> 
> Why did I get a 404 instead of the account page?
> 
> 
> 

An extension of this model is Selenium's [LoadableComponent](https://github.com/SeleniumHQ/selenium/wiki/LoadableComponent) concept.

As your site under test becomes more application-like and less document-like, the page object model becomes a leakier abstraction (at one extreme, imagine the page object for a single page application).

I mention LoadableComponent because I think they mitigate the "Bloated Page Object" problem, and part of their solution is overriding isLoaded and putting in custom assertions. From the docs:

> 
> The LoadableComponent is a base class that aims to make writing PageObjects less painful. It does this by providing a standard way of ensuring that pages are loaded and providing hooks to make debugging the failure of a page to load easier. You can use it to help reduce the amount of boilerplate code in your tests, which in turn make maintaining your tests less tiresome.
> 
> 
>
I would say no, don't put assertions in page objects. I prefer

* a consistent approach using the test framework DSL
* keeping to simple assertions that are self describing
* keeping page objects to more defined roles of locators, actions and services (sets of actions)
* seeing if there are multiple assertions (anit-pattern but common for ui tests) inline