How to run the JavaScript unit tests from Visual Studio.

In my previous post How to set up JavaScript testing in Visual Studio 2017 with Jasmine and Karma I created a Visual Studio 2017 suite for running JavaScript unit tests.

In that post I started the process of running the tests on the command prompt. There is also a way to start them from Visual Studio itself.
You can do that with the help of a taskrunner named Gulp.
Gulp is a tool you have to install; I’ll do that with the help of NPM.

Run this command in the directory your karma.conf.js file is located:

Npm install -g gulp --save


Now add to your project, at the same level as the karma.conf.js file, a new JavaScript file named gulpfile.js.

(I’m not sure why it must be called gulpfile.js or that it is completely mandatory to do so, but when I renamed the file it didn’t work anymore).

Then add the following content to this file:

var gulp = require('gulp');

var Server = require('karma').Server;

gulp.task('start-javascript-unit-testing', function (done) {
 new Server({
 configFile: __dirname + '/karma.conf.js',
 singleRun: false
 }, done).start();

This will create a gulp-task with the name  start-javascript-unit-testing.

This task will start a Karma server and then wait for changes in your (test-)code (like specified in the karma.conf.js file.

You will then also see this task in your task runner:


If you don’t have the task runner visible, use [view] [other windows] [task runner explorer] to show it.

If you double-click the task start-javascript-unit-testing a small window will be opened and the first run of tests will start.


Then, when you change the (test-)code the tests get re-executed for direct feedback.


Happy unit testing!

In the install of gulp, I used the -g switch which installs the package globally.

The NPM docs say “If you want to use a package as a command line tool, then install it globally. This way, it works no matter which directory is current. This is the choice you would use if you were installing grunt, for example.”; and grunt is sort of gulp.

But when I wanted to use the (globally installed) gulp in another project, I did have to install it local to that project too:

Npm install gulp --save


How to set up JavaScript testing in Visual Studio 2017 with Jasmine and Karma

At my current project I wanted to start testing my JavaScript code. However, there was no JavaScript testing code yet, so I had to set it up.
Should be no problem, I have done it before (ok, only once).
As with anything you only do once in a while (on most existing projects the setup is already done), you tend to forget the details.
So for you, and for me too: how to set up JavaScript testing in Visual Studio 2017 with Jasmine and Karma (in my case for testing plain JavaScript and KnockoutJS).

When all goes well, you have to take these steps:

  1. Create a test project (in your Visual Studio solution)
  2. Install Karma and Jasmine
  3. Configure the Karma runner
  4. Create tests
  5. Start the testrunner
  6. Enjoy

This of course is the happy flow; I’ll also talk about the little thing besides the happy flow I encountered.
I will show you this tutorial with this project:

This is a web solution which is an online calculator:
It consists of one HTML file and one JavaScript file which looks like this:

var Calculator = new function () {
    this.add= function (number1, number2) {
        return parseInt(number1) + parseInt(number2);


1 Create a test project

I’ll add a unittest-project; a project of type ‘Unit Test Project (.NET core)’.
The solution now looks like this:

2 Install Karma en Jasmine

If you are comfortable installing packages via NPM or you use another package manager, then just install these packages and go to step 3.

  • jasmine
  • karma
  • karma-jasmine
  • karma-chrome-launcher

If not, read on:
I use NPM as package manager. Visual Studio used to have a favor for Bower for client side packages, but I think NPM is more mainstream.
NPM stands for Node Package Manager and is, as you might guess, part of Node(JS). NPM is widely used for installing (client side) packages.
Check first if NPM works on your machine: open up a command window (with administrator privileges) and type ‘npm’ and enter.
If you get something like this
NPM is available and you can go to step 2b: install the packages.

If you get a message that NPM is not a valid command (‘npm’ is not recognized as an internal or external command, operable program or batch file.), read on:
NodeJS can be installed as a separate install, but when you installed Visual Studio with the webtooling option, you will probably already have a copy installed. That is because Visual Studio does it’s own install of NodeJS. It’s not very visible it does, and where it is located.
At my computer it’s located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Web\External\
As you can see the version of Visual Studio (professional) is in the path, so your location might differ. If you can’t find the path, just search for ‘npm.cmd’ on your machine.
If you can’t find it, you don’t have a NodeJS install and you should download and install it first from the offical nodeJS site , and then locate the ‘npm.cmd’ file.
Easiest thing to do is to add the location of the ‘npm.cmd’ file to your windows path, otherwise you have to always specify the full path when you run an npm command.

2b: install the packages.

So at this point you can run ‘npm’ in a command window.
Add, to your testproject, a NPM packages file. This will hold the names of all the NPM packages you will install:

Then go, in the still open command window, to the root directory of the testproject. This is the directory where the ‘package.json’ file is located.
In my case this is ‘C:\projects\git\Calculator\Calculator.Web\Calculator.Test’.
Then run, one by one, these commands

  • npm install –save jasmin
  • npm install –save karma
  • npm install –save karma-jasmine
  • npm install –save karma-chrome-launcher

I got some warnings and deprecated messages during this process, but it did not seem to break anything.
The ‘–save’ options makes NPM save the package to the earlier created ‘package.json’ file.
The ‘NPM install’ command creates a lot of folders (401 in my case) in a, also newly created, folder named ‘node_modules’.
You don’t have to include these in your project or sourcecontrol.
When I ran the commands in a second project, it somehow installed Jasmin version ‘0.0.2’, which is not ok. So after running ‘npm install –save jasmin’ check the ‘package.json’ file. If it says ‘”jasmin”: “0.0.2”‘ then replace it with ‘”jasmine”: “^3.0.0″‘ and run ‘npm install’ (without any parameters) and the correct version will be installed.

3. Configure the Karma runner

Karma will take care of running your tests, but for that it needs some information.
In the still open command windows (and still in the root of the testproject), run
‘node node_modules/karma/bin/karma init’.
This will ask some questions, answer them like this below.
karma-initIn this example the location of the source and test files is left blank; we will enter them later.
Because we installed the Karma Chrome runner, we choose ‘Chrome’ (case sensitive) for the browser.
When you are done a file ‘karma.conf.js’ is created; include it in the project.

4. Create tests

Time to create the first test.
In the ‘karma.conf.js’ we will add the paths to the sourcecode files as well as the files containing the tests. You edit the ‘files’ node and type the links to the files, all relative to the ‘karma.conf.js’ file.
If your source code is dependent on other files or 3rd library source files like KnockoutJS or JQuery, you will have to include the paths to those files here too.
In my solution I added  ‘./../calculator.web/wwwroot/js/calculator.js’ to point to the sourcefile and ‘calculator.test.js’ to point to the testfile (which I will create next)

Add a JavaScript file to your project, in my case it is called ‘calculator.test.js’
The content of the test is Jasmine specific (more info about Jasmine here) but it basically holds a description and the test (in ‘expect’).
It reads like this:

describe('calculator', function () {
    it('13 add to 16 should return 29', function () {

And now your first test is complete!

5. Start the testrunner

Run the following command in the still open command window:
‘node node_modules/karma/bin/karma start .\karma.conf.js’
This will run the tests (one at this time) and opens a (Chrome) browser.
If you add more tests and files and therefor edit the ‘karma.conf.js’file to include those files in the ‘files’ section, you have to stop the process and restart it in order to reload the ‘karma.conf.js’ file.

Now your test failed!

That is because there is an error in the test.
Now change the ’18’ to ’29’ in the ‘calculator.test.js’ file and save the file.
The test is rerun automatically and should succeed now.

6. Enjoy

Your first test now succeeded, celebrate it and head on for more tests!

What’s left to do for me is the following (which when I am done will create an article for too):

  • Run tests in Task Runner Explorer so I don’t have to run the command in the command prompt.
    Check. Created a post here How to run the JavaScript unit tests from Visual Studio.
  • Write tests in TypeScript
  • Test a TypeScript file (in stead of testing generated JavaScript)
  • Run the tests in Visual Studio as part of MS-Test

Azure pricing for Cosmos DB at Q4 2017

Azure pricing frequently puzzles me. “What parameters affect the pricing?”, “This is a cheap amount, is that real?”, “What can I expect as ‘normal’ use?” etc.
In the (not only interesting for the pricing subject) presentation from Pascal Naber at the TechDays 2017 (in Dutch) I saw an excellent slide about Azure Cosmos DB pricing:

Azure pricing for Cosmos DB at Q4 2017

What you can see the Cosmos DB pricing consists of 2 parts:
The first one is the size of your storage (in GB), is in the right column and probably makes most sense.
The second, in the left column, is the pricing for the number of RU’s per second you reserve ahead of time. And this needs more clarification.
A ‘RU’ means a ‘request unit’ and Microsoft calls defines it as “the measure of throughput in Azure Cosmos DB” (at the end of this article you will find a more verbose definition).
Now this is quite an abstract term: “a measure of throughput”, and that’s the reason I found this slide so valuable: it has some examples.
So here you can see a 1KB read is 1 RU, a 1KB write is 5 RU and a ‘select group by’ is 70 RU.
The numbers higher than one are probably estimates and will depend on request and response size but at least it gives you something to start with.

This slide is from October 2017 so the exact numbers and prices will probably vary with the time you read this.

The more verbose description of the RU by Microsoft:
A request unit (RU) is the measure of throughput in Azure Cosmos DB. A 1-RU throughput corresponds to the throughput of the GET of a 1-KB document. Every operation in Azure Cosmos DB, including reads, writes, SQL queries, and stored procedure executions, has a deterministic RU value that’s based on the throughput required to complete the operation. Instead of thinking about CPU, IO, and memory and how they each affect your application throughput, you can think in terms of a single RU measure.

Moving to HTTPS

I’ve been planning to move my business site to https for quite a long time now, and last week I finally made the move.

I requested a https certificate for my site from my hosting provider and after payment my site was https!

Of course there were some things to do on my site too, like replacing all the links to https (don’t forget the sitemap.xml) and setting up my local environment to be https ready.

Setting up my local environment for https was one thing that scared me but turned out to be really simple: create a personal certificate in IIS and use that for your site.

I found a great post by Max Vasilyev / Trailmax which shows all actions to take when moving to https:

So go to (or to – you will be redirected automatically) and you’ll be safe 😉


Different TypeScript function notations

In our project we use 2 different notations for defining functions in the Typescript files.In our project we use 2 different notations for defining functions in the Typescript files.One I call the ‘simple notation’ and the other one the ‘lambda notation’ (because it looks like the Lambda notation in C#).

private simpleMethodA(data: NavigationParameters): void { 


private lambdaMethodA = (data: NavigationParameters): void => {



I always wondered what the difference was. It turned out it makes a difference in the JavaScript that is generated:

MenuViewmodel.prototype.simpleMethodA = function (data) {



 this.lambdaMethodA = function (data) {



(in this method, the _this is declared like “var _this = this;” in the viewmodel).

So the simple notation is generated as prototype method and the Lambda method is generated as method on the viewmodel.