Unit testing Typescript/JavaScript Windows Store Apps with RequireJS and Angular

16 september 2014  |  
6 min leestijd

Hello again! It is time for my second blog post. Very soon after the first one, but that is because I am learning a lot these days and I am also using my blog as documentation.

Today I want to have a look at unit testing a Windows Store App written in JavaScript and/or in typescript. Normally unit testing JavaScript applications is not that hard. You will need to have a couple of components ready to make it work but there are a lot of standard frameworks and tools at your disposal. JavaScript unit tests get handled by different kind of components.

  • A unit test framework. You use this to describe and organize your tests.
  • A test runner. This does discovers your unit tests and runs them.
  • Browser. this can be a real browser with an UI or a headless browser like PhantomJS for example that will run your tests. A browser can be used for End to End testing, but it can also be needed to run all the necessary JavaScript. When you are not using NodeJS for example, you need something else to run the JavaScript. When you are using angular, you also need to run your tests in a browser.

When you are creating Windows Store Apps. NodeJS or a browser won’t help. This because Windows runs your apps in a special sandbox that is not easily simulated by a Node, a normal browser or a headless browser. This makes unit testing Windows Store Apps created with typescript or JavaScript from your automated build almost impossible. I did some research, but I believe that the only way to run unit tests for your Windows Store App is to create a separate project that functions as a test app to run your tests. The Hilo sample Windows Store App from Microsoft also uses this approach to unit testing.

So we are going to create a separate project in our Visual Studio Solution. This project contains all the files needed to run or JavaScript code. This means that you need to add the existing JavaScript files as links to your test project. I recommend creating just a blank Windows Store project.

Below is screenshot of where you can find this well hidden option in Visual Studio.


Once you have done this. All the files will appear as if they belong to your project but actually they don’t get copied. So any changes you make in a file will get shared between projects. This is what you want, all your changes will get tested.

Next up is the choice of your JavaScript unit testing framework. I did quite a bit of research on this and I found mocha.js the best suitable for Windows Store apps. Mocha has great asynchronous method support. So it can handle promises who finish later in a unit test without thinking the unit test is already done. Secondly, it can easily be run inside a browser, and not only in NodeJs for example. If it can be run inside a browser, it can probably be run in an app. Mocha let’s you choose an assertion framework, I chose should.js because it has a nice fluid syntax as you will see in a couple of minutes. Because I am also working with RequireJS and Typescript it took some tweaking to get all these thing working together.  Let’s have a look. First off is the HTML file. This is just a view to see our test results. It’s really simple. Here is the code.

From line 6 till the style sheets you can see my included of mocha.js and should.js and also a mocha.setup() call. Mocha supports different kind unit testing styles. I like the behavior driven development style. You will see this reflected in the way I write the unit tests. I could have also loaded these libs via require, but I did not see the point. The rest will get loaded via requirejs, because the app I am creating tests for also uses requirejs. To see howto handle this with angular and typescript, see my spanvious blog post here. On line 12 you can see a couple of div’s. Mocha will use these to report the results.

Let’s have a look at our test-main JavaScript file.

You can see the paths configuration for require starting on line three. What’s important here is that you config all libs you need, so you will find angular, domReady and your test files. You can see a configuration for my first test and a test for something that is called secondScreenController. On line 20 you can see the Require call, the callback will get executed after the dom has loaded and angular. In it on line 22 I create an angular module. I do this, because the services I am going to test also register them selves in that angular module as part of their code. Without this module being there, I will get an error during testing. After this module has been created, you can see on line 24 another require call. this call loads my unit test files. After they have all been in loaded in the dom I call mocha.run() on line 26. This will instruct mocha to go and discover my tests, run them and report the results in the html file.

Let’s have a look at a very, very simple class. Have look below.

This is a really simple typescript class. The only thing worth noting is that on line 1 I use the export keyword to define this class in RequireJS module. I do they so I can load this class in our unit test via require. Now the interesting part. The unit test.

This is where typescript shines. On line 4 you can see the import statement for my class under test. This is why in the test-main.js I only have load the unit tests. The unit tests themselves load the class they are testing. Easy with typescript Smile. On line 1 and 2 you can see the references to .d files for mocha and should. Otherwise the typescript compiler will give you a lot of errors about the describe and should methods. These describe functions come from the fact that I set mocha up to use BDD earlier, you can also choose another style of unit testing. First I describe the class, than I describe it’s different methods. You can find the actual test code in the body of the it functions. on line 11 you can see the fluent syntax of should.js, it’s really nice. Should.js attaches a method to the prototype of Object, so every object will get a should method you can use. You will need to do some extra stuff for null references. You will see that in another test. That test is shown below.

On line 11 you can see some null handling. This seems a bit weird but it is actually the recommended way when using should.js. On line 23 you see another cool feature of mocha. A call to the done() function that get’s passed in as a parameter for my test. This is used in unit tests that have async calls. Without the done() call mocha will treat the test as synchronous. If you do that call mocha will treat it as asynchronous and thus will wait with reporting until you actually flag the test done.

To finish this post. This is what I get when I run my unit test Windows Store app! it is not ideal, but still better than nothing.


I hope someone who wants unit testing in their Windows Store html JavaScript app finds this post useful. Until next time!

16 september 2014  |  
6 min leestijd


Luminis onderscheidt zich van andere aanbieders in de ICT door een waarde- en klantgedreven aanpak. Wij willen vooruitgang zien, zowel bij onze klanten als bij onze medewerkers. Graag komen we met je in contact om te ontdekken hoe we die kunnen realiseren.


©2019 Luminis Arnhem – Leveringsvoorwaarden

Design: Eyefun