Skip to main content


Showing posts from May, 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 - 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-

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 - How do you track defect-id of a failing test?

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

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 - 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 - What do you think of this approach? How