Tag Archives: testing

Refactoring is allowed

Writing automated tests means writing code. It means going through processes that regular code goes through. Like code review, and refactoring. I see a lot of hesitation when it comes to refactoring one’s own code, possibly because we feel that if our code needs correction, we did a crappy job writing it the first time. But that is not the case, and refactoring should be seen as a good thing. It is meant for changing something from good to even better. Continue reading Refactoring is allowed

A bug is still a bug

Do you know this situation, when you implemented some automated tests based on a requirement, but a test has been failing for ages because a bug in the implementation was never fixed? Continue reading A bug is still a bug

thewaiter: waiting for a URL in the browser to equal or contain a String, with Selenium

In some tests it is not enough to just wait for a page to fully load, but instead you need to make sure that the URL corresponding to that page is the expected one. Maybe you clicked on a button and need to make sure an expected page/URL opened, or maybe you are opening a page but a redirect changes the URL to something else than the initial page had. For such tests you can use the URL related wait methods from ‘thewaiter’ library, to wait until the URL is the correct one, before performing the rest of the test. Continue reading thewaiter: waiting for a URL in the browser to equal or contain a String, with Selenium

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!

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?

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

Selenium: How to wait for an element to be displayed / not displayed

In my previous post i talked about how to check whether an element is displayed or not. There are times when tests where such an action is performed fail randomly (sometimes they will pass, other times they won’t). The assumption here is that the element was not displayed within a decent amount of time when there were test failures, but would have appeared later on. Therefore if the test would have waited a little bit before performing the presence check, it would have passed. Continue reading Selenium: How to wait for an element to be displayed / not displayed