imalittletester

Selenium tests tend to make a lot of use of assertions, to check that some actions have been performed on the front-end or that some WebElement properties are the expected ones. And by assertions, I mean, mostly: assertEquals or assertTrue, as these are the most commonly used ones.

Assertions fail too often due to the condition they are checking not being fulfilled by the time the assertion code executes. Had the assertion run a few seconds later, in many cases, it would have passed. It’s all about timing. In my previous posts I described some of the WebDriverWait based methods you can find in my ‘thewaiter’ library. In this post I want to highlight how you can use these methods to replace your assertions.

• What does an assertion do? It checks whether a condition has been met, by the time it executes. What does the wait method do? It waits for the condition to be met, for a specified amount of time.
• What does an assertion do if the condition has been met by the time it executes? It executes successfully, meaning it does not throw an error. What does a wait method do if the condition is met by the time it executes? It executes successfully, meaning it does not throw an error.
• What does an assertion do if the condition has not been met by the time it executes? It throws an error, and unless you are using a SoftAssert, it stops any further test steps from being run. What does a wait method do if the condition has not been met by the time it executes? It waits, and periodically (every half a second) checks for the condition to occur, until the specified timeout period elapses or the condition occurs.

Thus, if the condition has been met by the time either the assertions or wait are running, there is no real difference between using an assertion or a wait. However, for the case when the condition was not yet met when the assertions or wait are running, there is a huge difference: the assertion stops and fails right then and there, whereas the wait keeps on trying, to give the test a higher chance of passing.

You could say that a wait is an “improved assertion”. It does check for a condition to occur, but it does not just check it once, as the assertion would. Instead the check is made as many times is possible, being limited only by the timeout period. This makes a wait method way more reliable than an assertion.

Also, because you are allowing the condition more time to occur by using waits, you eliminate the need for many retries of the test method execution. Retries of the assertion based methods will not bring any additional waiting time for the condition to occur, since what they do is just rerunning the entire test scenario and checking for the condition on the spot, right away, just like they did the previous few times they failed. You are basically rerunning the exact same code with the exact same time constraints, as it were. You are not giving the condition more time to occur, since you are redoing every test step from scratch. Coincidence will sometimes make your test pass at the second or third rerun, but unless you wait for a condition to occur, any time you run the test you will not have a guarantee it will pass.

So, what can you wait for? Well, almost anything you can assert. Below are some suggestions, that use the wait methods from ‘thewaiter’ library, and the comparison to what the corresponding assertion would look like. The ‘driver’ here means an instance of WebDriver, and ‘waiter’ is an instance of the ‘Waiter’ class from ‘thewaiter’ library.

• After opening a URL in the browser, you can wait for the URL to be an expected value. This can be useful when opening a page that causes a redirect to another URL.  This way you can check that the redirect took you to the expected URL.

Code with assertions

assertEquals(driver.getCurrentUrl(), url);

Code with wait

 waiter.waitForUrl(url, driver);

• After clicking an element, you can wait for the URL in the browser to be an expected one.

Code with assertions

webElement.click();
assertEquals(driver.getCurrentUrl(), "url");

Code with wait

waiter.clickElementAndWaitForUrl(webElement, url, driver);

• Checking for an element text to be an expected one.

Code with assertions

assertEquals(webElement.getText(), expectedText);

Code with wait

waiter.waitForElementTextEqualsString(webElement, expectedText,driver);

These are just some examples that should get you thinking about how to rewrite your assertion based Selenium tests, into wait based ones. Wherever you see an assertion (related to something that happens on the page), think whether a wait is not more suitable. It might not be the case all the time.

For example, if you need to wait for a WebElement to be displayed, and you need to check that several of its’ attributes have the expected values, then you don’t need a wait for each of these attributes. You can simply wait for the WebElement to be displayed, or for one of its’ attributes to be the expected one, and use assertions for the rest of the attributes. But this all depends on what you need to test and how your software is built, and you should really be aware of these aspects.