We are going to discuss two types of delays which should cover pretty much all cases you have to deal with: adding a global delay and waiting for something to happen.
#ICLOCK HACK HOW TO#
Here I am going to show you how to avoid inserting fixed delays in your tests.
You see, there is no winning with arbitrary delays: you either get a slow or a brittle test suite.
You might decide to add a few-second delay: this makes sure the page is definitely always loaded, but now your UI tests are taking longer and longer.You add a one-second delay to the tests hitting that page: in this case all of those tests are always going to take one second longer, even when the page loads fast, but even then the tests are not guaranteed to pass as the page might sometimes take longer then a second to load.You don't add a delay: in this case the tests that hit that page are sometimes going to fail which reduces your trust in the tests.Let's say that you have a page that normally takes less than a second to load but the tests hitting it fail every now and then because of occasional lag in response. You're waiting for some event to happen on the page which takes time.The page under test is slow because it loads a lot of data and/or queries a lot of tables.The web server, the database and/or the network are overloaded and busy with other requests.A lot of things could contribute to this delay. You have a test that fails intermittently and after some investigation you trace that back to occasional delays in the response For example, you navigate to a page and look or assert for something before the page is fully loaded and your browser automation framework throws an exception indicating the element doesn't exist. Don't worry I'll wait here.Īdding Thread.Sleep (or generally delays) feels like an inevitable hack when it comes to UI testing.
#ICLOCK HACK CODE#
Before going any further please read the previous article as I am going to refer to it and its sample code a few times. Much like the previous article the concepts and solutions discussed in this article are applicable regardless of the language and UI framework you use. I am going to use Selenium for the browser automation topics discussed in this article. UI tests fail more frequently then other types of tests, so how can we debug a broken UI test and figure out what caused the failure? In this section I show you how you can capture a screenshot and the page's HTML source when a UI test fails so you can investigate it easier.So I give you some advice on choosing the right selectors and targeting elements directly when possible. Browser automation frameworks target UI elements using selectors and it's very critical to use good selectors to avoid brittle tests.We discuss why adding fixed delays in UI tests is a bad idea and how you can get rid of them.In this article we are going to discuss a few advanced topics that could help you write more robust tests, and troubleshoot them when they fail: In the last article I talked about a few ideas and patterns, like the Page Object pattern, that help write maintainable UI tests.