Testing

This directory contains three levels of tests:

Unit tests (`test/unit`)

Should target functions and classes directly
Server should not be started
No external calls depenedencies should be hit
All tests must be independent to each other, order of tests must not change the result

These tests should be fast to run and limited in scope. They should be written if we have a specific function that needs rigourous testing, if you cannot think of a possible bug that the unit test would catch and the component test suite would not, do not include the test.

Component tests (`test/component`)

The "component" here is the service as a whole. These tests should:

1. Test the service as a black box

This means essentially calling the api then making assertions on one of more of:

The response
Calls made to external services
State changes in fake databases

The API can be called in or out of process. (i.e. you could use something like supertest or you could actually spin up the service and make http calls locally)

2. Use fakes/mocks/stubs for external depenedencies

Examples include:

In memory versions of databases (e.g. redis-mock)
Databases run in a local docker container
Mocked/stubbed servers running locally (ideally using pact)
Mocked/stubbed services running in memory (for example using nock)

3. As far as possible, not rely on previous test state

If you need a datastore to contain a certain state, this should be part of the test set up, it should not be the result of a previous test. In some cases this can lead to an excessive amount test setup code. In this case you can have a string of tests that are designed to be run in order but make sure the scope is well defined and they are all contained within a describe block (as small as possible)

4. Clean up after themselves

If a test uses a mocked/stubbed data store it should not leave any data in there that could mess with future tests (ideally the datastore is wiped after each test)

5. Not be integration tests

These tests should not call out to any external endpoints (you should be able to run them with no network connection)

7. Not be unit tests

You should not be testing individual methods from the codebase, as as a rule of thumb, all tests should be invoking at least one route

Integration tests (`test/integration`)

These are higher level tests that can be run against the service when it has no depenedencies stubbed/mocked out. These tests should:

Act as a sanity check for the service
(Ideally) Not assume any data is already present in databases etc
(Ideally) Be runnable against any environment
Be designed so that the service touches all of its external depenedencies

mgoria/readme.md