Unit Tests

How to write a new unit test

Writing unit tests is pretty straightforward but there are some things to consider.

Unit test file

The unit test for a particular class/file should have the same name as the class under test but end with unit.test.ts instead. This makes it get picked up automatically when our tests run.

Test structure

They generally follow a pattern like so:

suite(`My new unit test', () => {
    let foo: IFoo;

    setup(() => {
       // setup mocks
       foo = mock(FooClass); // Using ts-mockito to mock
       when(foo.bar).thenReturn(true);
    });

    test(`Test baz`, async () => {
       const baz = new Baz(foo);
       assert.ok(baz.bar, `Bar is not correct');
    });
});

Mostly we use ts-mockito to generate mock objects and sinon to stub out method calls.

Try to test public interface

In unit tests we try to follow the pattern of testing the public output of a particular class or function. Embedding internal details of a function class into a unit test ends up meaning the test is a copy of the function itself and makes it hard to maintain.

Debugging a unit test failure

When a unit test fails (or you're just starting to write one), you can debug the test.

From the debug drop down in VS code, pick this launch.json entry:

Then click on the gear icon and edit the --grep parameter to match your test.

You should be able to set a breakpoint directly in the test code.