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
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).
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.
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.
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
Most of the testing tasks require some data processing, whether it is working with JSON objects, gathering data from a database, processing Strings, working with date types, and so on. Performing the processing requires some code to be written, apart from the tests themselves. But why write that code yourself, if it already exists in an easily usable external library? Continue reading Better Test Code Principles: #3 Use external libraries when available