TypeScript unit tests best practices part 1: introduction

Insights and pattern proposals for more simple and maintainable unit tests with TypeScript.

As a code-clean enthusiast and a software developer for over 13 years, I have diving deep in themes like unit tests, project architecture and clean code. I learned and experienced a lot of different concepts and decided to write a series of stories to share my conclusions and perceptions of an ideal organization for unit tests in TypeScript projects.

Psst!

You can find part 2 here: IDE and Project Setup!
And part 3 here: definitions and rules,
And part 4 here: clean test suites structure,
And part 5 here: how to “unit test” (almost) everything in TypeScript!

First, let’s start talking a little about my motivations for doing this work.

The Freedom of NodeJS

NodeJS is simply an amazing platform. Is one of the simplest to setup, to start coding, to publish and to learn. Much of this come from the fact, of course, it’s base language is JavaScript, the most popular programming language of the time. JavaScript offers great flexibility and customization. Also, you have a lot of libraries ready to use, within your reach. But all this freedom and diversity comes with a price: the code style of projects easily differs.

In NodeJS, outside default npm commands, there’s little enforcement of how to do things and often you have two different ways of solving the same problem. When you work with multiple teams, this can become a great issue to deal with in the long term.

There is, of course, initiatives to establish different patterns and each team chooses the one that fits best for their needs, but there’s little official patterns enforcement along NodeJS core itself. Sum to this fact the great diversity of libraries, and you can fall in a scenario where, in a company with multiple teams, there’s no standards for node projects.

TypeScript, code quality and unit tests

Now, what can we do to enforce better coding and patterns for multiple node projects? I bet this problem can often occurs in many companies, but we’ll list here some tools that we consider a must have for node projects:

• TypeScript: excluding rare exceptions, I believe any node project must be written in TypeScript. Explaining roughly, TypeScript is a strongly typed language that can be transpiled to JavaScript. It can be of great help to maintain a consistent code;
• Code Quality tools: in the ideal scenario, your IDE doesn’t let you do something nasty, and quality tools can help you with it. They can deeply analyse, qualify, test and point out problems in your code that in other way could be detected only in production;
• Standardized unit tests: a good BDD unit test must be easy to maintain and to understand. When I say standardized, it’s because is quite easy for us to fall in errors when writing our unit tests that, at first, may help to deliver some demand quicker, but after can make the revisitation of this code quite traumatic. Respecting high standards for unit tests, we contribute for our future development;
• Clean code: also, if a code is very coupled, doesn’t respect SOLID principles, is too much complex, then, much probably you will have serious difficulties to write your unit tests. In my experience, a clean code helps to write your unit tests, and write unit tests helps you to maintain your code clean;

My proposal

All that said, the intention of the next stories is:

• To suggest a basic IDE configuration and basic packages that almost all node projects should have, that will help you to maintain your code clean;
• To present a standard organization for unit tests that aims to keep the code readable and simple, that uses the characteristics that TypeScript/JavaScript offers in our advantage;

So, thanks for read so far and I hope you enjoy the next contents!