Wednesday, 20 June 2012

After reading the blog post series looking at creating a testable application with a JavaScript by Peter Vogel which looked at setting up the server side and the client side view model using Knockout I couldn’t help but think JavaScript needs a way of doing a kind of dependency injection so it can be unit testable without the reliance on the server side.

I understand that it will have a reliance on the server side to output the tests, however this is down to the implementation of the project not a requirement of unit testing.

View model creation

The view model is setup in a very similar way to how Peter had it in his example with a couple of tweaks to allow for the “DI” to function.

We start by setting up the properties of the view model with the Knockout observables, set a reference to it’s self to be able to reference them later (good practice with Knockout from what I can gather), a callback binding function and the first “action” function on the model; getCustomer.

The getCustomer method calls into the data service passing in the parameters it requires for the action to execute and a callback function to call on the result. This could easily be expanded so that error handling can be caught and handled by another callback function but for this we’ll keep it simple.

With the view model set, the data service contract defined and being called in the function the view model is clean and not cluttered. At this point we can take a look at the data service “interface”.

Client side data service

The data service is built up with JavaScript object notation. The first two lines is to make sure that firstly there is a “MyApp” defined and it has a “Customer” property. Then the getCustomer function is defined with the set parameters required for execution and the delegate for the callback. Doing it this way you also add it into your own applications namespace and avoid cluttering up the global name space.

Lets look at the implementations for unit testing and for the actual application implementation.

The Unit Test

The test we are trying to pass is relatively simple and still based on Peter’s from the original series.

All it is trying to do is call getCustomer and make sure the data returned is bound to the correct properties.

Data service in testing

For testing purposes the view model test requires a populated JSON object to be returned from the data service. To enable the test to pass and remove the reliance on the server side test controller I create a mock client side data service before the qunit tests are added to the page.

All this is doing is following the contract/interface as defined for the data service, but instead of calling into a server side action it is returning a “mock” object. At this point we have removed the need for any server side calls.

After this has been defined we can now write our unit test (as above) and test that JSON object values which are being returned are bound to the correct properties.

Application implementation

So now we’ve created a mock data service and got our unit tests passing for the view model it’s time to create the actual implementation to allow for server communication and getting actual data.

As you can see we follow the same pattern as before but the difference is the getCustomer body implementation. We can now call into the server action and using jQuery’s $.getJSON method retrieve some json data from a server. The callback function is passed into the $.getJSON method which will delegate what needs to be done when the data is returned.

Conclusion

So to conclude client side unit tests do not need to have reliance on server side actions to execute even if they require data to be returned from an action. Some people may argue that the unit test isn’t testing the responses back from the server and handling them correctly. To do this you could go down the test controller route and get the server side to through actual errors or you could get the mock call to throw the errors.

Tuesday, 19 June 2012

I upgraded to the latest version of Asp.net MVC 4 at the weekend which is the newly released “RC” so thought I’d have a play and see what’s changed.

On doing File > New on a new MVC 4 / Web API project a newly clean crisp solution loads up in Visual Studio. Just out of interest I make sure it builds – can’t be too careful with these “pre-release” builds. The solution builds fine so it’s time to explorer …

I expand the project references to see what dependencies the project now has and the list is quite large. The usual suspects are there; EntityFramework, System.Web.Mvc, System.Web.Razor etc. but I’m greeted by some un-usuals.

Disclaimer: I’ll point out now I didn’t do this check on the Beta so I’m not sure if some of the following where there before.

The first one is new and expected; Newtonsoft.Json. We’ve been hearing for a while that json.net will be rolled into the final release and here it is. Nice! I’ve been using json.net for other projects for a while and it’s good.

The second two which seem out of place are “Antlr3.Runtime” and “WebGrease”. What on earth are these?

Lets look at WebGrease first …

It has an entry in the nuget package file with a version number etc.

In object browser it has some of the “Microsoft.Ajax.Utilities” namespace in.

The rest seems to do with css, ui etc.

Delete it and the app still builds and runs.

Guessing can live with that, but could remove it. What does it do?!

The other remains a mystery; “Antlr3.Runtime”.

No entry in the nuget packages

Remove it and the default app still builds

In object browser from the class names it looks like it does something with Tree structures?!

From doing some searching it relates to parsing grammers etc. to interpret them in your application. Why would that be shipped with asp.net mvc 4? Couldn’t find any documentation to support this so maybe it was an oversight and will be removed from the final RTM version. Will have to wait and see …