My last conference of the year recently wrapped up in beautiful Budapest. I took part, as a speaker, in 2 days filled with practical and useful advice, in a fantastic location. Continue reading My HUSTEF 2017 conference experience
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.
‘Twas a not so warm day in October, that in Vilnius awesome testers united to talk about their crafts. Some crushed candies, some with machines worked, others Selenium magic performed. And this is how it all unfolded. Continue reading My TestCon Vilnius 2017 experience
When automated test are running, they are either running on your own machine (when you write them or run them to check something), or in your CI.
When you run the test on your machine, if there are failures, it might be easy for you to look at what is running (if you have some visual tests, that interact with either browsers or apps on your machine). You can just rerun a failed test and visually inspect for failure reasons. But, if tests are running on a CI machine, visual inspection is either very difficult or even impossible. You might not have access to connect to that machine, or to see how tests are being run. Continue reading Test design: write tests with proper console output to easily identify failure reasons
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?
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
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