Code

Node API Health Checks and Uptime

Status code-based health checks are not enough. This simple example shows how to deeply test the functionality of your Node API, as a customer would experience, and ensure that everything is working as expected on every endpoint.
Example on GitHub

Example Server

The Node API used in this example is just a very simple RESTful implementation of a Users service. It doesn't connect to an actual DB of any kind, it just stores entries in memory.

Below is the basics of the express portion of the app,

These are the endpoints we will run against in the tests below.

Included is a basic fake authentication middleware so that we can demonstrate how to handle environment variables in Asserted tests.

Routine Configuration

In this case, the routine configuration is just the defaults provided when you run 'asrtd init' at the command line.

For this example we don't need any custom dependencies; the fixed v1 dependencies are sufficient and allow us to deploy faster as each push will skip the build step.

Environment Variables

It's likely that at some point you'll need to include some sensitive information like test tokens or usernames in your Asserted tests. Follow the instructions below to do so securely without saving these values directly in your git repo.

Included in the standard dependencies is dotenv and getenv. These are simple libraries that are commonly used to pull in secrets or configuration from environment variables.

  • dotenv loads environment variables from an .env file into process.env
  • getenv reads the variables out of process.env and throws if they are missing rather than defaulting to an empty variable

To access environment variables at runtime in Asserted, while still not checking them into your repo, do the following:

  1. Create a .env file containing the variables within the .asserted directory of your project
  2. Ensure that the .gitignore file inside the .asserted directory includes a reference to the .env file you just added (it should by default)
  3. Add an entry to the package.json in your .asserted directory for "files": [ "**/*.js", ".env" ], this will include the .env file in your package when you run 'asrtd push'

After doing the above, when you run 'asrtd push', you should see the .env file listed in the files includes in the routine package, while still omitting the file from your git repo.

Continuous Integration Tests

Writing integration tests for Asserted is relatively straightforward and essentially the same as writing an integration test for development reasons.

To start, if you have any environment variables, you should load those at the beginning of the test. This ensures that if required variables aren't present, the test fails immediately, rather than partway through.

Next, create a specific instance of got that includes the shared defaults for all API calls. You can also use one of the other http libraries included in the dependencies if you prefer.

Then, write whatever integration tests you like. In the example below, we list all users, create a user, update a user, and remove that user.

You can see a full version of this file here.

Next Steps

While the example shown here can be cloned and run locally without an account, you'll need to do a few extra steps if you want to create your own Asserted routine to integration test your API in production.

  1. Create an Asserted account. It's free and easy.
  2. Complete the 2 minute onboarding to ensure that your environment is ready. You can also reference the docs here.
  3. Start writing and running tests in prod!