I’ve decided to learn how unit testing can work in Javascript in order to start writing Javascript I trust. Here is my mocha example

Mocha

I decided to go with Mocha as my test framework as it seems pretty popular and I’ve heard good things about it.

Good old npm made it easy to setup as usual.

npm install mocha --save-dev

I decided not to bring in any assertion libraries such as Chai as it was a small project, relying on node’s assert library seemed adequate.

If any of my tests get more complicated I may look at other assertion libraries, but so far I feel that if a test needs a complicated assertion then the test itself is likely to be testing more that one thing.

Pending tests

One of the fetures of mocha that I was really impressed with was the ability to have pending tests.

If you call the “it” function with only a decsription, in the results the test will be show up as pending. This feature could be really useful to get all the requirements down first and work through them as a check list.

done()

If you have any asynchronous code that has a callback you’ll need to use the done method. Mocha passes the done parameter to each test, it can then be called from the callback function.

Without done, any tests that have asynchronous code will always return positive as the assertion will not have been called. This is one thing I didn’t like about mocha, for me, if a test has no assertion it should return negative.

describe('service(param, callback)', function () {
    it('should square the first param', function (done) {
        var param = 3;
        var expectedResult = 9;
        callbackExample.service(param, function (err, data) {
            assert.equal(data, expectedResult);
            done();
        });
    });
});

npm scripts

To run the tests easily I put the command in to the package.json, using the local install of mocha.

"scripts": {
  "test": "node ./node_modules/mocha/bin/mocha"
},

Refactoring

As with any unit tests, having mocha tests in place has made refactoring a lot easier.

When making applications in node, my code is much easier to break down in to small, testable modules. I find its a good rule of thumb that if code is difficult to test, it’s probably not designed very well.

Recently I’ve been looking at how a unit of work should be tested and asking myself the question “should every class have it’s own unit test?”

A test per class?

A lot of my unit testing historically has been around making sure every class is individually tested. Every dependecy in the class would be mocked so I could focus the test on the class itself.

However, I’ve been experimenting with testing a full unit of work rather than just each class itself. In some cases this might be a single class but only if the class covers a unit of work.

The boundaries

For my dependecies I now create a new instance of each so in effect I am still testing each class, just not individually.

These aren’t integration tests though. The boundaries will still be mocked out. The boundaries may be external, such as a database or an api, or they may be internal still, such as the layers of the application.

Refactoring

By focusing on the tests on what the code is trying to achieve and not the implementation I have found it much easier to refactor.

If a class or method is becoming too bulky and needs to be abstracted in to a new class for example, the test will still cover this new class while still ensuring the desired outcome is still happening.

With not having to keep in my head how all these little classes will fit together to perform the pice of work, my confidence in wanting to refactor has grown. When each little class is just tested individually, with no tests to ensure they are are fitting together I find I can be reluctant to start changing the design of the system.

Reveal intent

The increased scope of my unit tests from class to unit of work has helped not only my code, but helped my tests to follow one of Kent Beck’s 4 simple design rules;

Reveals intention

I’ve always taken care when naming tests, but now my names tend to be more useful. They have moved from names such as;

[Test]
public void GivenValueIsX_DependencyBIsCalled()
{
  //testing the individual class goes here
}

To something more like;

[Test]
public void GivenAFormPost_TheCorrectDataIsCalculatedThenStored()
{
  //here a call will be made to the controller
  //new up the required services rather than mock them
  //only the external call to the database would be mocked
}

Again, I’m finding this means I have to keep less of the systems reasoning in my head. I don’t have to remember why its important a certain service is called. The test will tell me why something is happening and test the result. It doesn’t care how I get there.

So should every class have its own unit test?

No.

Unless there is a good reason, such as external dependencies, each class should be covered by tests but not necessarily their own.

Here is another Linux command that I want to remember; the cat command.

My Linux command posts

These posts are NOT supposed to be exhaustive documentation for the commands they cover, but are here as a reminder for myself as I’ve found them useful and my memory is terrible.

The cat command

The cat (concatenate) command is pretty useful. It can be used make files, look at the contents of a file and combine files to make a new one.

Why I needed it

The task it came in useful for was to combine the logs from several days from several load balanced servers.

How I used it

cat file1.txt file2.txt > myNewFile.txt

Much easier than going in to each file, copying the contents, pasting in to a new file and remembering which files I had already done.

Here is the link to my other Linux command posts.

After setting up my first ASP.NET Core MVC site I’ve looked in to expanding it with a test project and taking advantage of more of the new features.

Test project

One of the first things I wanted to learn how to do in ASP.NET Core was how to get some unit testing going.

Firstly I set up the solution structure by creating a source directory and a seperate test directory. At the root of the solution I added a global.json file.

{
    "projects": [
        "src",
        "test"
    ]
}

In the test directory, to create the test project, there is a very helpful dotnet command.

dotnet new -t xunittest

This is a very helpful option to the new command. In the project.json file it sets the testrunner to xunit and the needed dependencies.

I’ve not used xunit before, but apart from a few syntax differences to nunit, it seems pretty straightforward.

For a mocking framework I went with Moq. It’s not my first choice, but I read it worked with ASP.NET Core so I went for it. Below is the dependancy to add to the project.json;

"Moq": "4.6.38-alpha",

Once all the tests are in place, you just need to run the following command in the test project;

dotnet test

The docs for testing in ASP.NET Core can be found here.

It was a big relief to find that setting up unit testing was straightforward as I’m loving learning ASP.NET Core and I didn’t want it to be a blocker.

Tag helpers

While in ASP.NET Core you can use Razor as your view engine, there are still some updates that you can take advantage of. On my little test site I was trying to set up a form by using the html helper begin form;

@using (Html.BeginForm())
{
    //form goodness goes here
}

However after reading through the ASP.NET Core docs I found the new tag helpers. I was sceptical at first as I’ve always found html helpers to be useful and didn’t particularly consider them needing replacing.

But now I’m a convert, tag helpers are pretty cool.

So my form became;

<form asp-controller="Home" asp-action="Index" method="post" id="usrform">
    <!-- Input and Submit elements -->
    <button type="submit">Get name</button>
</form>

No longer do you need to fill in the html helper’s signature, you just write the markup you need with the required attributes. For example to set the controller;

asp-controller="Home"

This makes the markup much nicer to read for everyone and removes that dependence on knowing how to use each helper. For example I would much rather read;

<label class="myClass" asp-for="MyProperty"></label>

Compared to;

@Html.Label("MyProperty", "My Property:", new {@class="myClass"})

I’m so glad I don’t have to remember that awful syntax for adding classes to html helpers.

_ViewImports.cshtml

In order to use tag helpers you need to make them available in a _ViewImports.cshtml file in the Views folder.

@addTagHelper "*, Microsoft.AspNetCore.Mvc.TagHelpers"

The above will add the tag helpers in the Microsoft.AspNetCore.Mvc.TagHelpers namespace. By following the same convention you can make custom tag helpers available as well.

Debuging

While unit testing massively reduces the need to use the debugger, I’m only human.

For a free IDE, the debugging capabilities of VSCode are fantastic.

Rather than using the VSCode launch.json and the built in debug launcher (since it’s not a console application), attaching the debugger to the running process worked well.

By running “dotnet run” from the source directory of the application the mvc site will be up and running. Then from the debug panel choose the attach to process option.

As you can see in the screenshot, the debugger is pretty comparable to debugger in the full version Visual Studio. You can set break points, watch variables and step through.

Static files

The typical location for static assets in an ASP.NET Core MVC app is in a folder called wwwroot at the root of the project.

Then in the WebHostBuilder set the content root to be the current directory.

var host = new WebHostBuilder()
    .UseKestrel()
    .UseContentRoot(Directory.GetCurrentDirectory())
    .UseStartup<Startup>()
    .Build();

host.Run();

Static assets will then be available by using a relative path to the wwwroot folder. For example;

<link rel="stylesheet" href="~/css/bootstrap.css" >

Example site

My example site so far is on Github here

As Linux continues to blow my mind, I thought I better start getting down some of the commands that I’ve been finding useful before I forget them.

My Linux command posts

These posts are NOT supposed to be exhaustive documentation for the commands they cover, but are here as a reminder for myself as I’ve found them useful and my memory is terrible. If they happen to help someone else, then awesome, and if anyone wants to let me know of any more, even better.

The grep command

The grep command is used for searching text for regular expressions and returning the lines that match. The result can then be output to a new file

Why I needed it

Recently I was asked to get certain details out of a very large log file. My first thought was to open the log in Excel and start filtering away. But then a Linux loving colleague showed me the grep command.

How I used it

grep "the text I was searching for" mylogfile.log > newfile.txt

I couldn’t believe how easy and fast this made a boring task. Definitely a command I need to remember.