Before you go, check out these stories!

0
Hackernoon logoMocha+Chai: Writing a reusable Test Suite for an expressjs/mongoose API by@timbushell

Mocha+Chai: Writing a reusable Test Suite for an expressjs/mongoose API

Author profile picture

@timbushellTim Bushell

20 years web development; leader in the elioWay; Quora Top Writer (2014-2018);

Here is a workable, reusable way to test an expressjs/mongoose application.

What we’re dealing with

It assumes the following setup; i.e. what every expressjs project could be expected to have:

project
   |- api
       |- app.js
       |- database.js
   |- test
        | test1.test.js
        | test2.test.js
        | ...

Stripped down, your app will probably look something like this:

app.js 

const bodyParser = require("body-parser")
const cors = require("cors")
const express = require("express")

const database = require("./database")

let app = express()

// Pretty standard API app
app
  .use(cors())
  .use(bodyParser.json())
  .use(bodyParser.urlencoded({ extended: true }))

// The article covers this later
database
  .dbconnect()
  .on("error", err => console.log("Connection to database failed."))

// Standard route
app.get("/", async (req, res) => {
    res.send("Hello world")
})  

// other... better stuff here!  

app.listen(5000, () =>
  console.log("Server started at port http://localhost:5000")
)

module.exports = app

Yep! Vanilla expressjs!

The bit to focus on is the line

const database = require(“./database”)
- an import which utilises a nice pattern to handle the Mongo connection implementation. Looking at the module imported will make sense of the
database.dbconnect()
call above:

const mongoose = require("mongoose")

const { MONGODB_URL } = process.env // or some other source of the cnn str

function dbconnect() {
  mongoose.connect(MONGODB_URL, {
    useNewUrlParser: true,
    useCreateIndex: true,
    useUnifiedTopology: true,
    useFindAndModify: false,
  })
  return mongoose.connection
}

function dbclose() {
  return mongoose.disconnect()
}

module.exports = { dbconnect, dbclose }

So that’s where we are. Nothing special… a simple expressjs app running alongside a MongoDB server using the mongoose library.

This article assumes you have an app already; we’re focused on testing it.

The cluttered approach to testing an express API

Let’s imagine how things might look in your tests right now.

test1.test.js
could look something like this:

describe("testing POST /wizard", () => {
  before(async () => {
    //before stuff like setting up the app and mongoose server.
  })
  
  beforeEach(async () => {
    //beforeEach stuff clearing out the db.
  })
  
  after(async () => {
    //after stuff like shutting down the app and mongoose server.
  })

  it("tests wizard creation", done => {
    request(app)
      .post("/wizard")
      .send({ name: "wizard1" })
      .end((err, res) => {
        res.should.be.tested.thoroughly.here
        done()
      })
  })
})

test2.test.js
not dissimilar, with a lot of repetitive garbage:

describe("testing POST /apprentice", () => {
  before(async () => {
    //before stuff like setting up the app and mongoose server.
  })

  beforeEach(async () => {
    //beforeEach stuff clearing out the db.
  })
  
  after(async () => {
    //after stuff like shutting down the app and mongoose server.
  })

  it("tests apprentice creation", done => {
    chai
      .request(app)
      .post("/apprentice")
      .send({ name: "apprentice1" })
      .end((err, res) => {
        res.should.be.tested.thoroughly.here
        done()
      })
  })
})

Repetitive and cluttered: If you agree, the purpose of this article is to look at a way of cleaning that all up.

A good deal clearer

First, we create a module; a single place we can put the repetitive clutter from all our tests. I will call this a “Test Suite”. To separate it visually from the actual tests, I would put it inside a

suites
folder, like so:

project
   |- api
       |- app.js
       |- database.js
   |- tests
        |- test1.test.js
        |- test2.test.js
        |- suites
             |- mochaTestSuite.js

Here is the scaffold of such a suite:

module.exports = (testDescription, testsCallBack) => {
  describe(testDescription, () => {
    before(async () => {
      //before stuff like setting up the app and mongoose server.
    })

    beforeEach(async () => {
      //beforeEach stuff clearing out the db.
    })

    after(async () => {
      //after stuff like shutting down the app and mongoose server.
    })

    testsCallBack()
  })
}

The more eagle-eyed among you will have noticed it isn't much different from the two tests we already have. It has two parameters. A description and a callback.

And this is how we intend to use it in, for example,

test1.test.js
:

// usual require stuff we will cover later
const mochaTestSuite = require("./suites/mochaTestSuite.js")

mochaTestSuite("the test description", () => {
  it("tests wizard creation", done => {
    chai
      .request(app)
      .post("/wizard")
      .send({ name: "wizard1" })
      .end((err, res) => {
        res.should.be.tested.thoroughly.here
        done()
      })
  })
})

The same eagle-eyes will also have noticed we haven't done anything much more than replace the

describe
function (which was originally in test1 and test2) with the new
mochaTestSuite
call — then delete all those before/after calls.

In fact, the two parameters - description and the callback for the tests - work in exactly the same way (in the test suite we’re writing) as they do in the bog standard

describe
function we normally use.

A Finished Test Suite

Rather than laboriously “then add this” and “then do this”… here is, without further preamble, a finished

mochaTestSuite
.

// test/suites/mochaTestSuite.js
const chai = require("chai")
const chaiHttp = require("chai-http")
const mongoose = require("mongoose")
const request = require("supertest")
const { MongoMemoryServer } = require("mongodb-memory-server")
const app = require("../../api/app.js")
const mongooseConnect = require("../../api/database")
const should = chai.should()
chai.use(chaiHttp)

module.exports = (testDescription, testsCallBack) => {
  describe(testDescription, () => {

    // Bonus utility
    const signUpThenLogIn = (credentials, testCallBack) => {
      chai
        .request(app)
        .post("/auth/Thing/signup")
        .send({
          name: "Wizard",
          ...credentials,
        })
        .set("Content-Type", "application/json")
        .set("Accept", "application/json")
        .end((err, res) => {
          chai
            .request(app)
            .post("/auth/Thing/login")
            .send(credentials)
            .set("Content-Type", "application/json")
            .set("Accept", "application/json")
            .end((err, res) => {
              should.not.exist(err)
              res.should.have.status(200)
              res.body.token.should.include("Bearer ")
              testCallBack(res.body.token)
            })
        })
    }

    // Database connector
    const clearDB = () => {
      for (var i in mongoose.connection.collections) {
        mongoose.connection.collections[i].deleteMany(() => {})
      }
    }

    before(async () => {
      let mongoServer = new MongoMemoryServer()
      const mongoUri = await mongoServer.getUri()
      process.env.MONGODB_URL = mongoUri
      await mongooseConnect.dbconnect()
    })

    beforeEach(async () => {
      await clearDB()
    })

    after(async () => {
      await clearDB()
      await mongooseConnect.dbclose()
    })

    // Run the tests inside this module.
    testsCallBack(signUpThenLogIn)
  })
}

A little unpacking:

  • See how the
    api/database.js
    setup we saw in the intro to this article, really helps us here?
  • The before/after is straightforward: Start the mongoServer; connect to it/Stop it; close it.
  • In
    beforeEach
    we clear the database, putting the clearing code into another function we can “await”.
  • The important bit is the callback
    testsCallBack
    . What happens is this. When you call
    mochaTestSuite
    , your
    it
    statements are wrapped into the callback function parameter we discussed earlier.
    mochaTestSuite
    first sets up the tests inside its own
    describe
    statement, running the necessary before and after statements, then it (duh) callsback the function you declared with one or more
    it
    functions.
  • I included a
    signUpThenLogIn
    function, which I will explain shortly. The point here is to show how all sorts of reusable code can be put into the suite, decluttering your actual tests.

Usage

Now we can declutter our tests like:

const chai = require("chai")
const chaiHttp = require("chai-http")
const request = require("supertest")
const mongoose = require("mongoose")
const app = require("../api/app.js")
const mochaSuite = require("./suites/mochaSuite")
const should = chai.should()
chai.use(chaiHttp)

mochaTestSuite("testing POST /wizard", signUpThenLogIn => {
  it("creates Wizards", done => {
    chai
      .request(app)
      .post("/wizard")
      .send({ name: "wizard1" })
      .end((err, res) => {
        res.body.name.should.equal("wizard1")
        res.should.be.thoroughly.tested.in.other.ways
        done()
      })
  })
})

Sweet. With all the before and after setup being handled by the suite, we can focus on testing functionality.

The

mochaTestSuite
has two parameters, the description and the callback function - which will (duh!) callback to run the actual tests inside
itself, having setup the app and mongoose servers for them.

And that’s it really.

But I promised to show you how the

signUpAndLogInfunction
would work. Some of your requests may need to be authenticated and it helps to outsource that clutter as well.

In fact, it works in a similar way, except

signUpAndLoginIn
’s callback parameter will be inside one of your it tests.

// requires as normal
const mochaSuite = require("./suites/mochaSuite")

mochaTestSuite("testing POST /apprentice", signUpThenLogIn => {
  it("Logs in Wizard can create Apprentices", done => {
    signUpThenLogIn(
      { username: "grandwizard", password: "IShallPass" },
      token => {
        chai
          .request(app)
          .post("/apprentice")
          .send({ name: "apprentice1" })
          // use the token
          .set("Authorization", token)
          .end((err, res) => {
            res.body.name.should.equal("apprentice1")
            res.should.be.thoroughly.tested.in.other.ways
            done()
          })
      }
    )
  })
})

So…

  • mochaTestSuite
    passes
    signUpThenLogIn
    into the callback.
  • In your tests (which require auth) use the function by passing in two parameters (the credentials and (surprise surprise) the callback to run the actual test post-login, using the token provided by the callback.
  • This would work for other types of login as well, not just token based login.

This also shows you how other features can be added to the test suite to
“outsource” the laborious, repetitive code that tests need just to get
them prepped for actually running.

Cleaner tests not only help with debugging but help other developers who might be looking at your tests to understand how to use your code.

Core, Thanks!

Author profile picture

@timbushellTim Bushell

Read my stories

20 years web development; leader in the elioWay; Quora Top Writer (2014-2018);

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.