Originally written by Jim Holmes
In an earlier post I talked about why developers should be more active in helping write automated UI tests. If you haven't read that post already, I'd encourage you to, because this post builds off that other one.
The TL;DR version of that earlier post: developers really need to be involved in what's going on at the UI testing level. Devs' involvement is a critical piece of overall success for a team's automation efforts.
Testing Kendo UI Applications
Regardless of whether it's Kendo UI Professional or Kendo UI Core, Telerik Kendo UI gives organizations a tremendous set of tools to quickly create amazing, responsive, performant systems. Even though Kendo UI makes it easy to build gorgeous UIs, teams regularly struggle with getting solid UI testing wrapped into their delivery flow. Teams often run into issues with asynchronous operations, difficult Document Object Model (DOM) structures, or browser incompatibilities that challenge team members writing functional UI tests.
Telerik Test Studio helps teams solve just these problems, and the terrific integration points with Kendo UI make it even easier. Moreover, Test Studio helps you create solid, flexible, maintainable test suites that won't kill you with high maintenance costs as your system grows. You can focus on delivering exciting value, rather than spending half or more of your time updating broken tests.
How Test Studio Helps Teams Deliver Great Software
Test Studio gives developers a number of great tools and features to work together with testers in building up powerful, flexible test suites:
- Visual Record and Playback for fast creation of high-quality tests: customize as much or little as you need in code via C# or VB.NET.
- Centralized element repository stores element locators in one spot, dramatically easing maintenance burdens.
- Translators that provide additional powerful features for working with Kendo UI and all other Telerik controls.
Test Studio comes in two versions: a plugin for Microsoft Visual Studio 2010 or later, and a standalone edition. The Visual Studio plugin brings all the features above right into Visual Studio; the Standalone edition supports all that plus load and performance testing. If you're working in an organization that separates its testers and developers then having both versions of Test Studio means it's easy for testers to record and modify tests, then hand off or work with developers to extend those tests with a small amount of code as needed.
Both versions of Test Studio support Telerik's scheduling and storage server, or you can integrate to your existing build, deployment, and execution infrastructure--you're able to make use of Team Foundation Server, Jenkins, Hudson, Team City, or any other build system. That makes it a snap to tie in with other unit and integration tests you (hopefully!) have running.
Getting Started with Test Studio
Haven't used Test Studio before? No worries--I'll walk you through it right now.
I'm using a simple Kendo UI Grid in the example for this post. I've built up a data source in a SQL database, and fooled around with getting an edit feature already hooked up. Now I need to add Create functionality. (I realize it's a bit backward, but it's how I rolled for this one. Cart, meet horse.)
Look Before You Jump (Or Write a Test)
Planning your tests is every bit as important as planning your production code--because tests are production code! In this case, we want to make sure the test is specific, accurate, and maintainable. We'll also need to ensure we're able to properly identify the elements we need on the screen so we can head off any potential problems with how Test Studio's recorder works.
Take a few moments to clearly think through what your test's purpose is: What's the business value you're trying to confirm? Are you sure you're working on a high-value test; something that validates critical functionality versus trivial look-and-feel? What steps will you take during your test? What data do you need? What verifications (sometimes called "checkpoints" or "asserts" in other systems) will you need? Do you need any helper functions or libraries to help you?
Once that's done, it's time to get a feel for how your test script will run. Regardless whether you’re using Test Studio, Selenium WebDriver, Canopy, or some other tool, all UI tests require a way to find or locate specific elements on the page you're interacting with.
Most UI test tools use some form of a page's Document Object Model (DOM) to locate elements on the page. Locator strategy is the most critical aspect of maintainable tests. Locator strategy is a post or four all on its own, but in general you should prefer use of ID attributes as your primary strategy if IDs exist on the element and aren't dynamically generated. Name attributes are a great fallback if an ID isn't present. Other options include CSS Class attributes, JQuery-style references, and XPath.
We can use Chrome's Inspector to check out the page's current DOM. Note the button and its corresponding DOM element. Currently there's no 'ID' attribute, but the 'class' attribute has part of its value as 'k-grid-add'.
Using ‘class’ for a locator is normally acceptable; however, below I’ll show you how easy Kendo UI makes it to create a perfect locator.
While we're here, we can also look at the Edit dialog and get a feel for its part of the DOM. Kendo UI nicely gives us 'name' attributes on each input field, so we're good to go.
Creating a Testable UI
Unfortunately, when you inspect the row of a Kendo UI Grid (or most other HTML grids, frankly), a problem appears: there's no ID. This row has no usable attributes at all.
We could approach this problem by building locators based on XPath or using the InnerText property of a row; however, both those techniques aren't optimal. We could also build a locator based on row position; however, that's nearly as close to a Worst Practice as possible because the test will break if anything impacts data on the table.