Please post your Web Driver questions in official Web Driver forum

Sunday, May 29, 2016

Where is my default Test Data

Importance of test data can not be emphasized enough whether we are writing automated or manual tests. With automated test we often deal with data objects. Data object is an object which encapsulates properties of data dealing with object. For example username and password could be encapsulated in to Credential object and passed on to required test methods.

But many a times we require default test data which can be used to facilitate system under test reach certain stage. How do we provide such default test data so that it is readily available for use? One way to deal with this is to use constructor on data object class which would initialize the data object with default data. In the following example TeamAttributes data object is initialized with default values -


Screenshot from 2016-04-20 09:59:30.png

Of course default values can also be read from a property file instead of being hardcoded as above :-)

And now if any of your test want to use default data then they can just instantiate data object class as-

Screenshot from 2016-04-20 10:03:49.png

What do you think of this approach of providing default test data? How do you handle default test data?

Where is my defect ID?

Don't you feel ecstatic when your automated tests find bug? After all tests finding bugs give us a sense of accomplishment, is not it? And this is followed by usual cycle of defect reporting, retesting and hopefully closure of defect.
But at times defects are deferred to next or future releases. Which causes test method to fail for subsequent releases. And if you are dealing with a test suite having 100s of tests then it may become difficult to remember if there was a defect reported for a failing test? How do you deal with such situation.
How about adding defect-id to @description tag of TestNG test. Hence it is reported on automated test report and we would know if defect exists for a failing test -


Screenshot from 2016-04-06 16:14:02.png

How do you track defect-id of a failing test?

Sunday, May 22, 2016

How "should" you name your test methods?

When writing WebDriver (or other automated tests) we are often faced with dilemma of how to name test method. For ex you may come across following test methods -


  • verifyLoginAsValidUser
  • verifyLoginAsInvalidUser
  • verifyLogoutAndLoginAsUserWhoSavedConsentOnLastLogin
  • verifyDefaultTeamSelection
  • verifyTeamDisplay
  • verifyMembersDisplay  

good enough, is not it? And if not then we can add more description about test method either in @description tag when using TestNG or on test method level comments. But what if test names were descriptive enough so that we don't have to resort to any of the other means ? Let's rewrite above mentioned test method names as -


  • shouldLoginUserWhenCredentialsAreValid
  • shouldNotLoginUserWhenCredentialsAreInvalid
  • shouldNotShowConsentScreenWhenConsentWasSavedOnLastLogin
  • shouldSelectDefaultTeamOnPageLoad
  • shouldDisplayTeamAttributesForSelectedTeam
  • shouldDisplayMemberLoginNamesForSelectedTeam
Here in test method names are based on format - Should<expected>_When<condition>. There is extended discussion on this topic on SO
Do you think these method names are more descriptive than what we used earlier? How would you name your test methods? 

Sunday, May 15, 2016

Introducing Navigation API for WebDriver tests

If you are working with selenium then probably you have used Page Object to make your tests more maintainable. In a gist, Page Object extracts the business logic away from test hence any future change in application would affect only one place - Page Object. When using page object we end up writing page / element level APIs which represent services offered by page. These APIs could be chained together to result in an array of operations, like -

Screenshot from 2016-04-05 12:24:54.png
Here in various page level methods are chained together to reach TeamsAndUsersPage (or any other page object). But this may not be only instance when you need to reach TeamsAndUserPage. Hence you would end up repeating/duplicating these operation through out your test methods. This is when we can create navigation package and add navigation class to facilitate navigation -


Also if you find that navigation is common in all test methods then you can add navigation as setup in test class -


Screenshot from 2016-04-18 15:54:16.png

What do you think of this approach? How do you get rid of duplicating page level navigation in your tests?
Fork me on GitHub