Test Driven Development | Assertions

In my previous post I began to chip away at the molehill of Type Driven Development. I’ll now step over that molehill and on to the mountain that is Test Driven Development. As explained in that post, Test Driven Development is focused around functionality of your code, i.e. when a function / code block runs does it behave as expected. Test Driven Development is all about bombarding your code with possible scenarios that could bring about unexpected errors. You can use these test results to tweak your code to make it more resilient and robust so that it fails during development rather than production.

Below is an example of what a Test Driven Development report looks like. The report is composed of three distinct components: assertions, a code runner and code coverage. Assertions are statements that run portions of your code and return a boolean pass/fail result. The code runner simply executes each of the assertions. The code coverage is the table at the end of the report. It’s essentially analytics used to ensure that you’ve actually written tests for all possible scenarios. There’s a lot to unpack here so for this post I’m going to focus just on the assertions part of the equation. I’ll be unpacking the remaining parts of Test Driven Development in the future.

Test Driven Development using: module, Mocha (code runner) & nyc (code coverage)

In the example above our first assertion test takes an array and passes it into a function that reverses it. The expected return value is . If the return value matches the expected value then our assertion test is true and we get a nice green tick. Let’s now dig into how we can get ourselves those ticks.

Assertions in Javascript

Some languages such as Java have native assertion capabilities. Javascript doesn’t have native assertion support. If, however, you’re using Javascript on the backend then you have access to the out-of-the-box Node.js module. You’ll also have the option to opt for an add-on package called in its place. is more expressive and has more depth — for that reason it’s many people’s preferred approach. but either option can get the job done. I’ll be doing a shallow side-by-side comparison of the two to show you what they look like.

The great thing about both modules is that the methods are incredibly descriptive and intuitive. Below are snapshots of the available methods.To use the module you just have to require it. To use the module you’ll need to install it first using Yarn/NPM.

https://www.w3schools.com/nodejs/ref_assert.asp
https://devhints.io/chai

Here is a simple example which shows how the and modules are similar. The syntax is identical for these basic tests and therefore they can be used interchangeably.

Identical tests for Assert and Chai

Here’s some useful assertions you can do with out-of-the-box which would require some more legwork when using the module.

Some useful Chai assertions

These examples may seem somewhat contrived at the moment. We’re building our way up to incorporating these assertions into a code runner such as Mocha. We’ll dig into that next week. Until then, happy asserting!

Full-Stack Web Developer | www.jordaneckowitz.com

Full-Stack Web Developer | www.jordaneckowitz.com