No Automated Testing

I generally prefer CSS selectors over XPath when writing Selenium locators. CSS selectors are concise, readable, and usually provide everything I need. However, there are situations where XPath is a better fit—particularly when I need to navigate through an element's hierarchy, such as moving from an element to its parent, grandparent, or sibling. This post shows one such real-world example. The Problem I came across a situation where I needed to click a link based on the value of an input field. The HTML structure contained multiple similar groups of elements. The input field and the link I wanted to click were not directly related, but they shared a common parent structure. In the following example above, the input element is highlighted, and I need to click the corresponding anchor ( <a> ) element . The challenge is that there may be multiple similar structures on the page. I therefore need to locate the link relative to the particular input element rather than using a f...

When writing automated tests we often check presence or absence of element for assertion conditions. This is usually written as -  assertTrue("Element is missing. Bug!!!", pageObject. isSomeElementDisplayed()); And when element is not displayed then above mentioned assert statement fails. In the similar manner we can write following assert statement to check for absence of element -  assertFalse("Element is present. Bug!!!", pageObject. isSomeElementDisplayed()); Above mentioned assert statement would fail if element is displayed on page. Everything looks ok, is not it. Not really, there is catch. Let's have a closer look at assertFalse statement we used above -  assertFalse("Element is present. Bug!!!", pageObject. isSomeElementDisplayed()); This assert statement would also succeed even if webpage results in 404/500 or any other error page, since error page would also be missing the element on which we are p...

I usually declare element locator static as well as the helper method using them, since element locators is a class variable or constant and is not dependent on a specific instance of class. For example in the following code snippet, element locators - imageElement and teamDeletionSucessMessage are static. Also, method - isTeamDeletionSucessMessageDisplayed is static - From one of the SO answer, following can be the requirement to make method static - If you are writing utility classes and they are not supposed to be changed. If the method is not using any instance variable(s) or instance method(s). {some thing I consider most important when declaring a variable static} If any operation is not dependent on instance creation. If there is some code that can easily be shared by all the instance methods, extract that code into a static method. If you are sure that the definition of the method will never be changed or overridden. As static methods can not be overr...

If you have been following page object pattern then you would have been abstracting page level operations in its own APIs. I usually write two types of page operations - Action API - one which are very granular and focus only on actions on one element Operation API - which can either combine various actions and constitute bigger operations or could call just one action API. For example when clicking on a link returns a new page object then following action API illustrates it - public MemberProfilePage clickNameLinkofFirstMember () { linkElement. click () return new MemberProfilePage ()     } And Operation API could be as simple as just invoking one action API - public MemberProfilePage acessFirstMemberProfile () { return clickNameLinkofFirstMember () } Or operation API can combine various action APIs to derive a workflow - @ Test public void shouldDsplayUpdatedNameWhenFirstNameIsChanged () { MemberProfilePage memberPro...

Have you come across use cases when you have create multiple element locators for almost similar element locators? Consider following text box, which gets date filled when user clicks on - expired, today, end of week etc links - This is how page html looks - And the element locators for expired, today etc link could be - "#coupon_expiryAt~a:nth-of-type(1)" "#coupon_expiryAt~a:nth-of-type(2)" There are other possible element locators but each link requires its own element locator. Now considering earlier example, the only difference in element locator is index number 1, 2 etc So what if we could get rid of creating different element locators and pass index number depending on the link we want to interact with? Let’s create base element locator - private static LinkElement getExpiryLinkElement( int index) {    return new LinkElement( "Expired Link" ,           By. cssSelector (St...