Avoid Unnecessary Verifications

I frequently see teams new to test automation making a number of common mistakes. One of those is adding in unnecessary verifications.

Verifications are obviously a critical piece of good tests—it’s validating the system is working as we expect for that particular test case. Where new automation crews get confused is whether to add explicit verifications when navigating through their application, or after an explicit wait has been used to handle an asynchronous operation like an AJAX call or some JavaScriptish operation on the local browser UI. (The same concepts work for XAML or mobile applications!)

Avoid Verifying Navigation

Let’s show the first situation of a needless verification around a navigation step. We’ll use the same demo application you’ve seen me work with hundreds of times over the last two years.

In this test we’re trying to log on to the system. First we navigate to the homepage, then we perform two separate verifications to check the link is visible and is enabled. Next we click on the Login link.

Both the verifications are completely unnecessary in this case. If the link wasn’t present on the page the click action would fail and the test would halt with the appropriate error messages.

Avoid Verifying Wait Conditions

Another common mistake is to add a verification for a condition you’ve just had an explicit wait around. A great example of this is AJAX operations such as the cascading menu from the AJAX Control Toolkit Examples. Users make three menu selections and a result message appears with the type of car they’ve chosen. Each of the menus and the final result message are populated by an AJAX call which returns elements to update the local DOM with.

To get this test to pass we need a number of explicit waits to deal with the various AJAX calls. The final explicit wait specifies the exact text we’re waiting for in the result message.

Adding a verification of the result message would be pointless in this case. The explicit wait was built around the result message itself. Remember how explicit waits work: the wait step loops between sleeping and checking the DOM for the condition we’ve specified—the result text in this case. The loop only breaks if a timeout occurs (the condition wasn’t met within a certain period), or if the condition is met.

If our condition was met, it means we’ve seen the correct result text updated on the DOM. There’s no need for a specific verify step because our test has already passed!

Adding unnecessary verifications is, well, unnecessary. It makes your tests longer and harder to read, and it can also incur unwanted maintenance costs if your verifications are built around conditions that are dynamic or may change as the system grows.

Keep your tests concise, specific, and don’t bloat them up with unneeded steps!

Avoid Extra Verifications—Except When You Need Them

Remember that the only Best Practice is “There are no best practices!” There may be cases where you may need to add in verifications of the sorts I’ve spent this blogpost telling you to avoid. Use some critical thought and ensure you’re only adding those when they’re absolutely necessary.

Happy Automating!

About the author

Jim Holmes

Jim Holmes has around 25 years IT experience. He's a blogger and is the Director of Engineering for Telerik’s Test Studio, an awesome set of tools to help teams deliver better software. He is co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.

Interested in chatting with Jim at a conference? Check out his speaking schedule!