-
1. Re: Graphene Abstractions - Best Practice for Assertions
jhuska Apr 15, 2014 7:42 AM (in response to otinanism)1 of 1 people found this helpfulHello,
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
-
2. Re: Graphene Abstractions - Best Practice for Assertions
otinanism Apr 15, 2014 8:31 AM (in response to jhuska)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
-
3. Re: Graphene Abstractions - Best Practice for Assertions
jhuska Apr 15, 2014 11:40 AM (in response to otinanism)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.