In this post i will discuss the methods you can find in thewaiter library, for waiting for a page to load completely. I will show the methods you can use from thewaiter that can help you with these waits, and some test examples for each, that you can also find in GitHub. Continue reading thewaiter: opening a page and waiting for it to load with Selenium
Category Archives: automation
Introducing thewaiter. A WebDriverWait based library for writing reliable Selenium tests
During my talk at the recent SauceCon conference, i described how you can write reliable Selenium tests by using WebDriverWait based methods to wait for page events to take place. I am now happy to announce that my little project, thewaiter library that i mentioned in the talk, is available to use from the Maven Repository! Read on for details. Continue reading Introducing thewaiter. A WebDriverWait based library for writing reliable Selenium tests
The tester and the code review
Code review, although very important and frequent in the software development world, is not as frequent in the automation testing world. Normally, it would be part of the whole process: someone writes code, reviews it, makes it available to the rest of the team, they review it, and if changes are needed they will be made, and the improved code will now be available back to the team. This helps in having better code and having awareness inside the team on what is being implemented.
Code is still code, no matter whether it is created for implementing or testing a feature, so there should be code reviews for all of it. Continue reading The tester and the code review
Automated testing of translations by using property files
Whenever you need to write tests that check for a text in several languages, you don’t need to write one test for each language that you check for. Instead, you can use property files to store translations and just write one test that will check the text across all supported languages. Read below to see how and checkout my GitHub project for the examples presented in this post. Continue reading Automated testing of translations by using property files
Write automated tests with repeatable results
Writing automated tests is no longer the biggest challenge in the testing community. Writing reliable automated tests is. So many times tests that were once written are sent to the garbage bin or thrown into oblivion. They are unreliable and people will just ignore them when they are running, simply because they have a history of failing for various random invalid reasons. Continue reading Write automated tests with repeatable results
Why you need to test your production environment
It occurred to me lately, after chatting with some people from the testing community, that not everyone runs automated tests or does any kind of testing in the production environment. For me that seems a bit unnatural, since i have been doing it on all the projects that i worked on. So, here are a few thoughts that might convince you that you do need to run automated tests even in production: Continue reading Why you need to test your production environment
Checkout my article for TechBeacon on Top 5 Apache Commons utilies for automation engineers: https://techbeacon.com/5-best-apache-commons-utilities-automation-engineers
TestTalk on why automation is fun
Checkout the talk i had with Joe on why automation is fun and why you should also get into automation: https://joecolantonio.com/testtalks/183-test-automation-fun-corina-pip/
Happy listening!
Check that the value you think you typed into a field has actually been typed correctly
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.
Test design: write tests with proper console output to easily identify failure reasons
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
