Dev Ops: Test Driven API Development Environment (Node,Express,Type Script)

With the advent of Cloud based Apps, Continuous Development and Integration have become the cornerstone of using Dev Ops to manage Cloud Services. In order to ensure that the continuous deployment of those services are smooth, a comprehensive set of tests must be available to catch any fatal issues before going live. This is where Test Driven Development(TDD) is most useful as it allows the developer to create a series of tests which evolve with the application. A subset of those test can be then repurposed to check if any upstream changes would break the release.

This article will detail how to setup a TDD environment for API’s specifically for Node, Express and Type Script. Future articles are planned for deploying the initial application using Docker on Kubernetes and implementing a Continuous Integration pipeline.

Packages

You should have Node installed. We will use it together with Express to create our back-end API. Let’s create the project directory and initialize it. For the purpose of simplicity, I assuming a *nix environment.

mkdir chatserver
cd chatserver
npm init

Just hit enter to take the default options. This should create a package.json file in your project.

npm install typescript --save-dev
npm install @types/node --save-dev
npm install ts-node --save-dev

Typescript provides useful typing to Javascript which in my personal opinion creates better code. I’ve also installed the types used by node and the REPL typescript wrapper for it called ts-node. While we are at it we might as setup the tsconfig.json file as well which provides parameters when we compile to Javascript.

The next set of packages are purely used during the test driven development process.

npm install mocha @types/mocha --save-dev
npm install chai @types/chai --save-dev
npm install supertest @types/supertest --save-dev

Mocha provides a test framework. Chai is an assertion library that expands on Node’s assert. Finally SuperTest providing a way to test your API interfaces.

Lastly, the next set of packages are used to develop our API. If you couldn’t guess, we are developing an API for a Chat Server.

npm install express @types/express --save

Configuration

We are finally ready to setup our environment. Let’s create a couple of directories to organize ourselves. In project root directory do the following:

mkdir src

This will be the directory for your Typescript code.

mkdir tests
touch tests/hello.test.ts

The tests directory where mocha will look for your tests. I have also created an empty ‘hello’ test script that we will expand on later in this article.

mkdir dist

This directory is where the typescript compiler will put the Javascript code used in production. You can also add this directory to your .gitignore if it isn’t there already.

Now add the following to to your packge.json. There are 4 options here.

npm run start

This command will start a server without tests.

npm run test

This command is just run all tests under the test directory from the terminal

npm run develop

This command will watch for changes in the src directory and test directory and run the tests.

npm run build

While technically not need at this stage, this will compile your Typescript into Javascript putting it in the dist folder.

Let’s just write a simple test, open up the hello.test.ts file and add the following:

You can either do an npm run develop or npm run test. So this is your first test, which sends a GET request to ‘/’, and expect some json data in response. The test obviously fails. So let’s try to fix that.

So add the above to your src/server.ts. This should let the first test pass.With your TDD development environment is setup, we can starting writing more tests, have them fail and fix them to pass.

Conclusion

So hopefully I have helped getting started on the road to writing better code and reducing potential bugs. TDD is hard for some people to transition to but committing to it pays off in spades.

TDD can be useful for in several ways in the ‘real’ world. Senior Developers could write the tests based on better understanding of the requirements and get a junior developer to implement them. On-boarding new developers are easier as well as a self documenting/sand-box environment is readily available for them to use.

You can get the finished setup here.