Skip to main content

Playing around with jasmine

I believe like a lot of devs that javascript is going to become more prevalent in a lot if not all areas of application development, whether that be with a server side framework like node.js or client side with frameworks like backbone.js & knockout.js. I've built a couple of sites with backbone and I'm very interested in what Derik Bailey is doing with marionette, but with all my investigations into backbone I haven't as yet put any of the javascript I've written under as serious testing strategy.

A quick search for a BDD style testing framework lead me to jasmine, I've heard good things and I thought I'd give it ago.

What to put under test with jasmine?

Previously I implemented a simple undo-redo framework for .Net called, this was pushed out to GitHub and I thought I'd port this to javascript. The important issue here is not the ported-code but how easy I found it to get jasmine up and running.

First off downloaded & unpacked Jamine from here. I then created a new folder and copied in the Jasmine lib contents:
Next I had to create an entry point for the testing, this probably as you expect is a html page. I lifted the code from the jasmine examples. I also created a folder for the specifications that will be written in javascript:
As said this SpecRunner.html is a generic file which will load all the required spec & source javascript files.

As you can see from the comments in the above screen-shot we aren't currently including any specs or source files. Before running any tests I wanted to make sure everything was working, so spinning up SpecRunner.html in a browser and I got the following:
It works and in less than 5 minutes, time to start testing...

Converting to javascript gives the following javascript object declaration, I've collapsed down the function implementations just so we can see the function signatures:
This was placed in the root folder and an include statement was put in the SpecRunner.html:

Where are the tests specs?

They are defined in the spec folder, in this case I've created one called UndoSpec.js. The first test is shown below along with the include statement for the SpecRunner.html file, hopefully you can understand this but if not, it tests for an expected exception when the undo action is undefined:
The spec is highlighted, above it is the beforeEach function and if the name doesn't give it away this is run before each spec - just like in C# being annotated with the Setup attribute for an nUnit test.

Now when I run SpecRunner.html I get the following output:
The describe function definitions don't have to be a 1 to 1 relationship with the behaviour, you can have multiple behaviours. The following extract also demonstrates another feature of jasmine, custom matchers. They basically allow you to hide non important implementation detail so your specs remain readable:
The custom matcher is part of the SpecHelpers.cs which is also an include statement in the SpecRunner.html file. The customer matchers are also added before each spec as part of the initialisation:
After adding all the required specs as describe functions I get the following output from SpecRunner.html - clean, clear and to the point.
 And the spec folder ends up looking like this:
To me this pretty much demostrates low friction BDD :)

All that was left for me to do was upload this to GitHub, I even managed to create a NuGet package and I'm going to create a Ruby gem if I can workout what to do :)


Popular posts from this blog

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v