Why does this framework work?

Going from no code coverage to a high percentage is intimidating. There are so many tests to write! Instead, take advantage of the fact that not all parts of a codebase are equally important. There are mission-critical components, and then there are supporting components. This framework ensures that:

The most critical parts of your application are tested first. As you make progress, you are able to subsequently cover less important parts of your application. By writing tests for all new code you write, you are able to get yourself into the habit of writing tests. As you write tests, you see your coverage numbers go up, which incentivizes you to keep going.

What about Test Driven Development?

Many people preach Test Driven Development, but in a startup environment, it is not always practical to adhere to it because it does slow down development.

If you do not have the engineering resources to practice TDD, I believe the next best thing is the method that I mention above.

Choosing the right type of test

There are many different types of tests: unit, functional, integration, performance, etc. I recommend writing unit tests first because they are usually:

The least fragile

The fastest to write

The fastest to test

Unit tests let you quickly boost code coverage. After you write a decent amount of unit tests, move on to writing a few integration tests.

What to do after writing the tests

Tests are pointless unless you are constantly able to view their state. It’s imperative to be able to the following on every commit:

Which tests passed and failed?

Which parts of your code were covered?

This is one of the primary reasons why I prefer writing tests using Jest, a testing library from Facebook. They have built-in code coverage reporting via Istanbul, which is extremely useful. Without it, there’s no way to ensure that the important parts of your code are covered.