Image may be NSFW.
Clik here to view.

A big part of using the MVVM pattern is separation of concerns, and to make testable code. Why is it then that ViewModels in Kendo UI apps are often left untested?

For me, I always find myself trying to test parts of my ViewModel, until I end up having a direct reference to a DataSource in it. For example:

At this point I usually wasn’t sure how to test with the DataSource being there, since it would attempt to get data from the server. Then I would just give up on testing (shame on me!)

So, how can we write good unit tests when there is a Kendo UI DataSource involved? With Mockjax!

Prerequisites and Setup

We are going to write some tests around the DataSource and ViewModel above. You can use your JavaScript testing framework of choice, but I am going to use Jasmine. Either Jasmine 2.0 or Mocha will have almost exactly the same tests, since their syntax is almost the same, and the way they handle asynchronous tests is the same.

We will use the mockjax library to mock our jQuery AJAX calls, which will make the Kendo DataSource think it is communicating with a server, but it is in fact being intercepted by mockjax.

Setup your Jasmine test runner to import jQuery, Kendo, and Mockjax. Note that Kendo and Mockjax are both dependent on jQuery, so it needs to be imported first. Then you can import your own text files. In this example, the test spec file is named “DataSourceTesting.spec.js”

Getting the ViewModel

One of the frequent problems with writing testable JavaScript is heavy use of singletons or object literals. For example, simply specifying viewModel = kendo.observable({…}); can be a problem to test, because now we only ever have 1 viewModel object. If a test modifies any field on this object, it needs to be reset before the next test. Forgetting to do so leads to side-effects from running a test.

There are several ways to deal with this, but for this example, I am simply going to define a function that returns a new, unmodified ViewModel obejct for each test.

Testing Read Operations

The basic layout for our test specs is:

So you can see that a new ViewModel object will be created before each test. This ensures the tests don’t have side-effects.

Now lets define our first test; We want to test the peopleCount function on the ViewModel.

This test will cause an error, because the DataSource will request data from the “api/people” URL when its .read() function is called. This is where we can use Mockjax to intercept that AJAX call, and return a known set of data. We do this using the $.mockjax() function to setup URLs to intercept.

Now when DataSource.read() is called, Mockjax sees that the “apipeople” URL should be intercepted for “GET” requests, and returns the data assigned to “responseText” to the DataSource.

Since AJAX calls are still asynchronous, we use the Jasmine 2.0 “done” callback function. We also need to wait for the DataSource to signal that it is done reading, which is accomplished by waiting for the next “change” event.

Mockjax Clear – Avoid side effects

Since we added a mockjax mock during our test, we need to remove that before our next test, otherwise our mocked ajax handlers will persist to the next test and could have nasty side-effects.

You can remove all mockjax handlers by calling $.mockjaxClear() in the afterEach callback in Jasmine, so that it will be run after each test.

Testing Create and Update

That works great for reads, but what about creates and updates? When you create a new record, Kendo UI wants you to leave the default value for whatever is specified as the schema.model.id field. In our example case, “id” is a number, so we should leave it set to 0 to indicate a new record. This will then be sent up to the server, and the server can reply with the same object that was passed to it, but with the id filled in. Let’s make sure this works.

This time we have our mockjax handler set up to watch for “POST”s to the URL, and to only intercept the AJAX call when an exact data item is posted to it. It will then reply with an object with a known id of 3 set on it.

We wait for the next “sync” event from the DataSource to know that it has processing the response from the server, and can then assert that the id of the object was changed to what was returned by the server.

Also notice that where our last test used “responseText” in the mockjax settings, this test uses “response” which is set to a function. This function just sets “this.responseText” to the data that should be sent back to the client, but I wanted to include it to show that you could do additional processing in this function if needed.

Testing Deletes

We can test deletes much the same way, however in our previous tests, we waited for the DataSource to finish processing the server response, then made some assert on the data. In this test, I demonstrate how you can run your asserts and call Jasmine “done()” directly from the mockjax “response” callback function if desired.

Testing Errors

You may have noticed that when the DataSource that we have been using for these tests was defined, it had an error handler:

Fortunately, Mockjax provides are really easy way to simulate a server error. Instead of setting “responseText” in the mockjax settings, you can use “status” instead to set an HTTP response code. If we set “status:500″ then the Kendo DataSource will run the error handler, and we can test that the “hasError” flag is set properly on the ViewModel.

Troubleshooting

If you have issues where Mockjax returns undefined to your DataSource instead of real data, make sure that you have dataType:”json” set on BOTH your DataSource and in the Mockjax options. I found that if one or the other was missing, then Mockjax would return either undefined, or just a string representing the JSON data, but Kendo would not JSON.parse it.

When mockjax intercepts AJAX calls properly, it will log them to the console:

Now you have one less excuse not to test your Kendo code! Go forth and test!

The post Unit testing Kendo UI DataSources with Jasmine and Mockjax appeared first on Falafel Software Blog.