You are writing some automated tests with Selenium, that require you to fill in some text fields in a form. You are pretty confident you typed the values you expected to type, into the field you expected to type into. But, here are just 3 reasons why you should write some code that checks that you actually wrote what you thought, where you thought, before submitting the form you are trying to fill in.
Let’s say you have a task to check whether a certain image is broken on your page. In case of a broken image, instead of it being rendered properly on the page in your browser, you will see a suggestive icon, like an X or something similar (depending on the browser), suggesting that it’s broken. Continue reading Checking whether an image is broken with HttpClient
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
I am back from the SeleniumConf UK 2016 event which took place in London, and i have to say, it was a fantastic experience. I have seen some really great talks, got plenty of takeaways, and as an added bonus, as a speaker, i managed to get a sneak peak ‘backstage’.
All the talks are freely available, which is a major plus for this conference, so have a look Continue reading Lessons learned at SeleniumConf 2016
Selenium 3 has been announced a long while ago, but it is only recently that beta versions have started rolling out. The latest beta version, 2, is now available for you to try. Continue reading Selenium 3 beta version 2 available for you to try
In my previous post i talked about how to check whether an element is displayed or not. There are times when tests where such an action is performed fail randomly (sometimes they will pass, other times they won’t). The assumption here is that the element was not displayed within a decent amount of time when there were test failures, but would have appeared later on. Therefore if the test would have waited a little bit before performing the presence check, it would have passed. Continue reading Selenium: How to wait for an element to be displayed / not displayed