Graphene Abstractions - Best Practice for Assertions

[otinanism]

Hello all,

I started writing my tests using the Page Abstractions provided by Graphene (Page Objects and Page Fragments).

I am trying to decide on what is the best practice for writing assertions. Specifically I am trying to decide where the assertions should be located. Should it be on the Page Fragment, on the Page Object or on the Test class? I am used on having all assertions on my Test classes but that is the "old" way.

For example, asserting if an element has a css class could be done in the following ways:

// not working code just  an example
@Test
public void simpleTest(){
     assertTrue (pageObject.getElementA.isDisplayed());
}

or

@Test 
public void simpleTest(){
     pageObject.isElementADisplayed();
}

where pageObject  is a Page Object as defined by Graphene:

public class PageObject {
     WebElement elementA;
     public isElementADisplayed(){
          assertTrue(elementA.isDisplayed());
     }
}

Also the page could as easily define a Page Fragment which in turn could have the assertion.

Is there an obvious best practice for this?

Thank you in advance.

Alex

[jhuska]

Hello,

there is a recommended way by WebDriver itself, to put assertion exclusively into tests. You can find it here:

https://code.google.com/p/selenium/wiki/PageObjects

We found this way a right choice as well, and we are following it. IMHO the Page Objects and even more Page Fragments need to be as much reusable as possible. Specially with Page Fragments you often want to assert different conditions from test to test.

Hopefully I helped you with my explanation

[otinanism]

Thank you Juraj your answer is helpful indeed!

For page fragments I understand  completely the point of reusability. It gets a bit blurry for me in the case of Page Objects. Let's say that I have a Page Object called userPage which is a user details page with two fields Lastname and Firstname and a Save button. When I click save and the operation is successful I want the form to be cleared. I have a method in the Page Object which is called from the actual test:

  public void assertFormIsClear() {
        assertThat(editUserFieldSet.getLastName().getAttribute("value"), is(""));
        assertThat(editUserFieldSet.getFirstName().getAttribute("value"), is(""));
    }

Where editUserFieldSet is a Page Fragment.

How would you rewrite this method so that assertions are on the test?

assertTrue(userPage.isFormClear());

and then what would the isFormClear method be?

public boolean isFormClear(){
     return editUserFieldSet.getLastName().getAttribute("value").equals("") && editUserFieldSet.getFirstName().getAttribute("value").equals("");
}

If that is the case I don't really see the point of asserting on the test case, do I gain any encapsulation?

Thank you again for your answer!

Alex

[jhuska]

Your example is how I imagine to rewrite it.

However, the statement: assertions should be in Page Objects is IMHO more advise than rule. What is more important for me, is keeping a consistency across whole test suite, so it is is not confusing where the asserts are actually done.

This is why I like keeping assertions in the tests:

• it is more clear when one is looking into the test method what is method actually testing, what is expected, what are actual results
• if the test fail, I prefer to firstly find out the cause from the failing message, but then I usually need to check the test as well, then I found more easy to see the asserts there, and not to look for them in various classes
• I found naming of the Page Object methods more clearer if they do not do asserts, the more concise and meaningful PO methods are, the more test is readable

But please take those as just my opinions, and it can be viewed in totally different view, and still valid. There is no pattern recognized yet. In our team, we do it like I described it.