Category Archives: automation

The tester’s daily dilemma: my automated tests fail because of the test environment. What can i do?

Automated tests. They are there, and they need to be run. On a test environment. By you. You wrote them in a way that they should be reliable, when the features under test work as designed.

But each day you run the same tests on the same test environment, and they fail. Not because the feature under test is not working properly. No. Because of external factors, and by external i mean: hardware issues, network issues, other services that are underlying to your own but are not in your control. And to make it an even more awesome experience, each day you the run the tests, they fail when performing a different step than the one they were performing the day before when they failed. Continue reading The tester’s daily dilemma: my automated tests fail because of the test environment. What can i do?

Checking whether an image is broken with HttpClient

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

Removing all digits, non-digits, whitespaces (from Strings) and other usages of replaceAll

Some tasks will require you to replace all occurrences of certain Strings from other Strings with something else, based on a pattern. Or remove all those occurrences. For example, maybe you want to only keep the numeric characters of a String. Or remove all numeric characters. Or maybe remove all white spaces. For this, the replaceAll method comes in handy. Continue reading Removing all digits, non-digits, whitespaces (from Strings) and other usages of replaceAll

Identify the OS tests are running on with os.Name or SystemUtils

In order to make your tests OS agnostic, sometimes, you need to create some additional logic to handle OS specifics. For example, if you are running Selenium tests, on a browser, you want the test to run on all OSs, not just one, and start the browser instance corresponding to the OS the tests run on.

For that, you need to first identify what OS the tests run on. That can be done either by creating your own OS detection code, using the os.name system property, or by importing an existing class that does the work for you, named SystemUtils.   Continue reading Identify the OS tests are running on with os.Name or SystemUtils

Using Maven checkstyle in your project to help adhere to coding standards

Coding standards are something both automating testers and developers should adhere to. Pretty obvious right? Maybe not that obvious might be some of the rules you should follow when writing the code for your tests. Checkstyle is here to help in standardizing your code, so that you can get an early feedback regarding code improvements (earlier than the code review step anyway).  It allows you to define a set of basic coding rules that must be followed in your project, and it gives you the opportunity to make your builds fail if someone breaks those rules. This post addresses using checkstyle from a Maven project, by means of the dedicated Maven plugin that you need to declare in your project. Continue reading Using Maven checkstyle in your project to help adhere to coding standards

Better Test Code Principles #5: Mind your try/catches

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).

Continue reading Better Test Code Principles #5: Mind your try/catches

A three-course menu for writing your Selenium tests before the feature is complete

How many times does this happen: you start a new iteration/sprint; you give estimates; you realize that the testing work will not be complete in the sprint for certain features?

While analyzing the work that needs to be done in a sprint you tend to think in a sequential manner: developers write the code –> only once the code is complete will the testing begin –> the developers are done with their work within the sprint, the testers are not. Strategies, workarounds and intense thought processing are used to determine how to somehow fit the testing work in the sprint, to not allow it to flow over into the next sprint. Is there an alternative? Yes.

Continue reading A three-course menu for writing your Selenium tests before the feature is complete

Using Lists to get UI elements with nearly impossible selectors

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.

Continue reading Using Lists to get UI elements with nearly impossible selectors

Better Test Code Principles: #4 Keep your production tests separate from your dev environment ones

Automated tests are used to validate features in development environments but also in production. Whereas the classic approach of keeping all tests in the same code project is the most popular, it is not the best idea (and by code project i mean for example a Maven project). Continue reading Better Test Code Principles: #4 Keep your production tests separate from your dev environment ones