First Look at Testing a Kendo UI Data Grid

Telerik's Kendo UI provides a number of easy-to-use, flexible controls — or widgets — for developers working with HTML5 and jQuery. You've probably been using websites and applications built with Kendo UI already - Test Studio's new recording engine uses some of the Kendo UI control set.

As a tester, you're likely more interested in how to use Test Studio than how it was built, and this is the first of a series of posts for you.

One of the first Kendo UI widgets I used is the Data Grid (you can find my example code on GitHub, if you're so inclined). This is a great way to build a table based on a data source, and make it sortable and filterable without needing a lot of code.

Here's a simple test, in Test Studio, to make sure that a particular value is displayed in a grid cell:

There's nothing special to see there, it's pretty basic. At some point in our product's development, however, we note that our test starts failing...

... and if we look closely during test execution, we can see a difference in the cell. Note that the cell now appears to be selected, and there's a cursor as though the user can type into the cell.

While we've got the test paused in the debugger, let's take a look at the DOM and see what we can find. Look carefully at the row in question, compared to the row just above it. In the row above, we can clearly see a TD element with the text "Cavalier." In the row we're expecting to find, however, the contents of the cell are very different:

Ah, here's a clue - remember, the result of a test, whether "pass" or "fail" is a piece of information for us to learn from.

Instead of the expected text, we see an Input element. It's no wonder that our test is complaining - it's looking for a TD element with "Clubman" as its text. We can see that there's no such thing to be found.

This gives us something meaningful to talk with the developers about. Even better, let's take a look at the code ourselves first.

Even if you're not a developer, or don't know anything about JavaScript, jQuery, or Kendo UI, I think this is fairly readable. This is the definition for our kendoGrid, and the first few lines indicate the source of the data and the columns to be displayed. Then we appear to have some configurable parameters, and you might see something interesting here. Remember that in the DOM we saw an Input tag instead of text, and we had noticed in the browser that the cell was selected and had an editing cursor. Line 29 enables the grid's editing functions. It's a good bet that at some point that one line was changed or added and now is causing the difference we're seeing in our test's behavior. There's a specific conversation we can have with the team.

There are a couple of things we can learn from this. First, we probably didn't need the second step in that test - if we remove or disable (un-checking the box in the list of steps) the Click step, the test runs just fine. When the click does happen, Kendo UI changes the cell from simple text to an input field, just as it would have for a user. No click means no change, and the cell would still contain simple text for our test to find.

More importantly, we also learned of a change to the application, so perhaps having that click step was a good thing after all - now that we know the grid is editable, there's probably a whole lot more testing to be done (and we should be asking who made the change, and why).

Kendo UI makes rich user interfaces simple, and in this example you can see a bit of that power — changing one parameter turned a simple table into an editable grid. It was also fairly easy for us to discover the change during testing; you can imagine comparing this to having to dig through custom code.

Is your development team using Kendo UI yet, and are there particular widgets that you're finding challenging to test? Let me know in the comments here or over on Twitter. And as always, if you're not already using Test Studio, there's a 30-day free trial waiting for you.

Peace,
Steven

About the Author

Steven Vore

Steven Vore (@StevenJV) is an Evangelist for Telerik's Test Studio. He has worked in software support and testing for the better part of two decades, and enjoys exploring ways to make software easier to use. Steven is a fan of movies and music, and spends more time on Twitter than is likely healthy.