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
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
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
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
It all started over 6 months ago. I heard about Nordic Testing Days being an awesome conference and i really wanted to be a part of it, as a speaker. Having never been to Estonia, the location was also a nice plus. So i submitted some talk ideas and the guys from the organizing team were kind enough to accept me as a workshop deliverer…workshoppee…well a speaker who does workshops. Continue reading My Nordic Testing Days 2017 conference experience
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
This is something i heard quite a few times: why bother writing automated tests, as they will not find any bugs anyway? Continue reading A false myth: automated tests don’t uncover bugs