Q2 Webinar Recap: Testing HTML5 and AJAX With the Telerik Testing Framework

Last Friday, 20 June, we presented a webinar on using the Telerik Testing Framework (TTF) to solve problems automating functional tests around HTML 5 and AJAX. We also recorded the webinar—you can view it via the embed below, or in HD directly on Telerik TV.

We had a very interactive session, so I thought it would be handy to cover a few of the most interesting questions and responses from the webinar. Some of these are covered in the webinar itself, but they merit inclusion here too.

Q: Is it possible to use stubs if we use IoC (inversion of control).

A: Mocks, stubs, etc. enable teams to write tests that decouple dependencies on external systems. These approaches are a critical part of any good automation strategy; however, I feel they’re inappropriate at the functional test level. Functional tests should focus on high-value features of the system, and they should exercise the entire, live system. The one edge case I’d consider would be chopping out ancillary systems which don’t directly impact on the feature being tested—services rendering ads on a page would be a perfect example of this.

Q: How do I use jQuery-style selectors with the Telerik Testing Framework?

A: TTF supports a fluent language approach to jQuery selector strategies. Please read a great blog post walking you through the details.

Q: Can you specify multiple browsers for the same test when using Manager.LaunchBrowser()?

A: No. Instead create the browser outside the scope of your individual tests and pass the browser into each test through parameter injection. This lets you write the test independently while still leveraging TTF’s great multi-browser support.

Q: Doesn’t opening the browser actually slow down the tests? Is there a way to avoid actually opening a browser window?

A: Yes, starting a browser session does indeed slow down tests. There are some technologies that support “headless” browser tests; however, I feel very strongly that these do not replace browser-based functional tests. The whole point of functional testing is to ensure your application works in the various browsers with all their unique quirks and “personalities.”  Headless tests are a great, fast integration-level test, but you shouldn’t skip full-blown browser testing.

Q: Can you convert a test recorded in Test Studio Standalone to code?

A: Yes. The Visual Studio plugin enables you to export a test to code. Note this is a one-way operation, so you’ll lose any upgrades or enhancements to recorded steps with future versions of Test Studio.

Q: Can you use regular expressions with selectors?

A: Yes! However, be aware of the old joke “If you use a regular expression to solve a problem then you have two problems.” (Actually, I personally love regexes. They’re a great tool. Use them wisely.)

Q: What would be the best way to use TTF on several different browser versions, IE7, IE8, IE9, eg.?

A: All test runners, not just TTF, execute the current version of the browser on that particular system. The best way to support multiple browser versions is to have small systems or VMs with the exact environment you need on them. Run your test suites via agents on those particular systems.

Q: Why did you say Thread.Sleep() isn’t recommended for dealing with timing issues due to AJAX calls?

A: Thread.Sleep() kills kittens. Or something like that. Please stop using it, or other manual execution delays, for dealing with asynchronous timing issues. Thread.Sleep() leaves a hardwired, non-dynamic pause in your tests. Its delay is always present and most often leads to unnecessary, inflexible time sinks.

Instead, always, ALWAYS use an explicit Wait for the condition you need to proceed with the test. If you need a menu item to be present after a search, then wait for the menu to hold that specific content. If you need a tab to be active after submitting a record, then set up an explicit wait on that specific tab.

The best thing about explicit waits is they’re dynamic. A Wait immediately checks to see if the particular condition you set up is met. If not, the Wait sleeps a moment, then checks for the condition again. This pause/check cycle continues until either the condition is met, in which case the test continues, or the timeout period (default 30 seconds) expires, in which case the step fails.

Please stop using Thread.Sleep() or other manual execution delays now. You’ll sleep better.

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!