The Mocha test runner uses ts-node to load our TypeScript test files, compiles them to JavaScript, and executes them. The files are then evaluated for their suite context, and each test within the suite is evaluated in sequence. The actual test is incredibly fast itself due, in large part, to the extensive mocking we are doing for the Express application request and response behaviors.

Our test assertions are written using the expect keyword from Chai, followed by a series of very readable chain methods for what the expected values should be. These assertions are very useful and flexible for composing the test criteria you want to assert. The Chai assertions library includes dozens of different assertions that can be composed in many different ways depending on the needs of your application. The Chai Assertions APIs are illustrated in the following table:

expect({a:3}).to.have.ownPropertyDescriptor('a',{
  configurable: true, 
  enumerable: true, 
  writable: true, 
  value: 3
});

Object.prototype.b = 2;
expect({a:1}).to.have.property('b')
.but.not.own.property('b');

function Foobar () { }
expect(newFoobar())
.to.be.an.instanceof(Foobar);

var error = function() { throw new Error('Error!'); };
expect(error).to.throw(); expect(badFn).to.throw(TypeError);

function Foobar() {} Foobar.prototype.method = function() {};
expect(new Foobar()).to.respondTo('method');

function Foobar () {} Foobar.prototype.functionMethod = function() {}; Foobar.objectMethod = function() {}; expect(Foober).itself.to.respondTo('objectMethod')
.but.not.respondTo('functionMethod');

In reality, this unit test isn't fully complete. There are additional unit behaviors we may want to assert in our test, such as if logger creates a log file successfully, or if unauthorized returns the correct error state. However, now that we've covered the process of implementing successful mocks of Express application behavior, these tests should be possible for you to flesh out fully on your own.