How to separate your test, development and production databases using NODE_ENV.

Why should you separate your test, development and production databases?

As your applications become more complex you're going to incorporate different methods of testing to help ensure that your application works as intended. Of course this doesn't make your application 100% bullet proof, which is why proper testing is important, but why is it important to separate our testing environment from development and production? When running test suites, there is usually some degree of changes made to the database in the form of updating entries, adding, deleting, forcing errors etc. We want to make sure that when we run our tests, they don't rely on previous data to ensure that one test doesn't influence another. An easy way to do this is to implement some clean up method before and after a test is run, which usually means clearing a database and filling it with the same dummy data.
Running a test suite on a production database would be irresponsible because a test might have unwanted side effects and alter the state of our database, or worse it would reveal information about our tests and source code. The data inside of the production database is always changing as well, which means that a test suite might work one day, but fail another day because the same data was altered causing our tests to fail.

How to separate application environments using NODE_ENV

We can store environment variables in the node process (highly encourage you to read up on this if you're not familiar). Then we can access any of these variables in any part of our program. These variables are also secure so it is common to store API keys, credentials and other secrets inside of the node process. When running our node applications we can set the NODE_ENV and conditionally change the applications settings based on this NODE_ENV. It is a common practice to store these variables as key=value pairs inside of a .env file shown below.

The environment is set to development by default and one implementation of this is found below by changing our the URI to our database.

This does not have to be used with mongoose, it was just an example. But depending on the environment our application will use a different database. This can be used to change the settings of other features as well, maybe you want to enter a testing environment for stripe, or sandbox environment to test an SDK.

How to set NODE_ENV

Now that we know how to conditionally render settings using NODE_ENV, how do we set NODE_ENV when running our application? A common approach is to set them in package.json scripts:

{
  ...
  "scripts": {
    "start": "NODE_ENV=production node ./app"
  }
  ...
}

This way you can start an app in either a test, development or production environment.

Comments

[slidenerd]

instead of this , you should make 4 different env files and simply change the values and load the right file depending on environment