Jasmine with SharePoint – Part One

I have seen a few projects and articles that focus around how you can work with Jasmine (BDD) and SharePoint Applications (or Add-ins as they are now called), but little going into the complexities of how you can incorporate this way of working with SharePoint projects.

That is the purpose of this article, to talk about how you can fit BDD into the development process, when working with JavaScript in a SharePoint project.

What is Jasmine and who is BDD?

Not to be confused with TDD (Test Driven Development), BDD or Behaviour Driven Framework is designed to improve how you code and not just verify that the system does what it does (as TDD sometimes tends to do). It is designed as a alternative and answer to the problems that TDD introduced.

Jasmine is a Behaviour Driven Framework for specifically testing JavaScript code from the ground up. Before you start developing, Jasmine encourages you to write tests to fail against your code. You then start to introduce JavaScript code to build the required functionality, which continuously gets tested against your tests (known in the Jasmine world as Specs).

So as you code, you are refactoring to not only build the functionality you need, but to pass the Spec(s) that you created at the beginning of the process – with the idea being that this improves the quality and coverage of your final code (as well as testing what you are creating against different browsers and scenarios automatically).

Some Key Fundamentals

There are three key considerations to keep in mind when looking at incorporating Jasmine into your development workflow:

  • Create your spec(s) at the beginning of the process (test to fail)
  • Abstract your code where possible (use mock objects for where you normally make data calls)
  • We are not testing OOB functionality or Data!

Working with Jasmine

We have focused up until now on the fact that you need to create Specs from the outset to test your JavaScript code, but what about the other parts of Jasmine?

If Specs are our test cases, then a Suite is the encapsulation of Specs, grouping all of our Specs together.

The next thing you need to know about are matchers. Matchers are what we use to evaluate if a condition is true within our Specs. OOB, there are a bunch of matchers that you can use, such as toBeEqual, toBeNull (full list of standard Jasmine matchers)

The thing to note about Matchers, is that they always evaluate to true or false. You will also note that the way the matchers are named, they are very descriptive and this is not a mistake. Everything that we do with Jasmine, should be what it says on the tin.

Along side Specs and Matchers, we need a way to run our tests and this is known as a Test Runner. The most common Test Runner is called Karma and it runs on nodeJs. Fear not, it’s relatively simple to get Karma, Jasmine and your Specs all up and running on a windows environment and even integrate it with Visual Studio.

Abstraction

The key thing about working with Jasmine in SharePoint is abstracting what you are doing from the SharePoint code base. Wherever you can do this, you can incorporate Jasmine BDD into your development process (so yes to reading and writing to REST endpoints and no to display templates).

Remember, that you are not testing SharePoint functionality and you should not be using Jasmine BDD to test data. If you adhere to these principals, you can soon start to write Specs and Suites.

Getting setup

This is all a lot of information, so it maybe quicker to get you up and running and to see some examples. So let’s do the first of these and prepare your environment to use Jasmine and Karma.

Install jsNode, npm (think NuGet for jsNode). Next up, use the npm command in the following Karma readme and then make sure you have the Visual Studio 2013 extension which can be found here.

I would heavily advise in installing a command line alternative, such as ConEmu, which will play alot better with jsNode and Karma. This can be run only when you need it and it will not replace the system one.

Once you have all of this up and running, you can get real time Jasmine testing, integrated into Visual Studio as you code (more on this in my follow up post).

Examples

In this Examples section, I’m trying something new by providing each example in an embedded lab (JSbin) and the code snippet (GIST).

So to start, I am going to show an example which will show all of this working together outside of the realms of SharePoint first, just to make sure we understand the following:

  • How to Create a Jasmine Suite and associated Specs
  • How to create Mock data calls
  • How to use Jasmine with Knockout
  • Show a range of standard Jasmine Matchers in action

Jasmine – Working with Knockout

So let’s take a look at this in detail, jump into the GIST:

SharePoint

So let’s take a look at the first SharePoint Jasmine suite, with an example that tests against a script that creates a list item.

Jasmine – Spec for SharePoint Example

To take a look at this in detail, jump into the GIST:

jQuery Jasmine

Often you need to manipulate or change the DOM and this is where jQuery Jasmine comes into play. When you create Specs that need to test against the UI, jQuery Jasmine can give you the matchers you need to test against all things visual.

Jasmine jQuery Spec Example

To take a look at this in detail, jump into the GIST:

Summary

In this article we walked through how to create suites, specs and utilise matchers to test DOM elements, Knockout views and a SharePoint script.

In the next part of this series, I will talk about how this can be integrated into a SharePoint project to produce reports as Quality Assurance artefact(s).

Jasmine with SharePoint – Part One
Tagged on:     

Leave a Reply

%d bloggers like this: