One of the most common ways of interacting with a page displayed in a browser, in Selenium tests, is clicking on a WebElement. But many times, due to the timing when the click happens, it will fail, since the WebElement that needs to be clicked is not yet available. This might be because some Javascript events have not finished enabling that WebElement, or other similar issues. Making clicks reliable can be done by using WebDriverWait, to wait until the click can actually happen.
Using try/catches to handle exceptions has become quite fashionable when writing tests with Java. However, this approach is also a frequent source of having false positives while running tests. Many times when writing the tests people forget to consider both sections of this code block: they forget to write the appropriate code in both sections – the code that deals with not encountering the exception (if the code in try executes) and the code that deals with encountering the exception (if the code in catch executes).
Where does this approach apply? One of the following:
if you have a list of elements with identical selectors. The element you are interested in is an element of that list. But it does not always appear in the same place in the list. Sometimes it might be the third element in the list, other times it might be the second, or the fourth, and so on. You only know that using getText() on the element returns a known text.
if the element you are searching for has a different selector each time you open the page. You know only the type of element it is (whether it is a button, or an a element representing a link, or an img element) and what text should be displayed on that element.
if the element you are looking for does not even have any attached attributes. That means it is only a tag, without an id or class, or anything else except for the tag name (tag being ‘a’ for links, ‘img’ for images, and so on). You know what getText() should return when applied to that element.
This is going to be a rather complex post, that will show how to easily check for values of similar UI elements. By similar i mean elements that share some kind of properties: whether they have the same CSS selector, or are part of the same group of elements. Some examples will be shown below. Performing the testing part will imply the use of @FindBy (of Selenium WebDriver) and List (of Java). Read on to get an idea of where this approach can be used, how @FindBy is ideal for such a task, what the basics of working with List are, and what an actual test looks like. Continue reading @FindBy, Lists and using them to check for similar UI elements→
When starting to learn Java, one of the first things you are taught is that a class consists of several things, among which are the ‘methods’. A method is nothing more than grouping of several code lines. Since tests are code, the same principle applies to writing your Java based tests. Especially if you are dealing with duplicate code (code you keep copy/pasting all across your test project).
This is going to be a follow-up post in regards to the approach i showed at my SeleniumConf talk, on doing Selenium tests by using an Object Oriented approach.
When you are faced with a task that involves using lists, you might want to consider the following question: are the elements in my list ever going to change, or is it enough to just add my elements to the list once and use them across my tests. Is my list a constant? In case your elements will not change, you can use an ImmutableList to store them, which brings a major advantage: defining a list in one line. ImmutableList is part of the ‘guava’ library. Continue reading Working with lists: ImmutableList→
