Simulating request error with async function

Question

In my express app, I declare request handlers like this(simplified here):

export const CreateProduct = async (req, res, next) => {
  try {
    // ProductModel is a sequelize defined model
    const product = await ProductModel.create(req.body)
    res.send(product)
  } catch (err) {
    // I have raygun setup as the error handler for express
    // in this example, it will finally return 500
    next(err)
  }
}

And then use it like so:

import { CreateProduct } from './create_product'

export const ProductRouter = express.Router()
ProductRouter.post('/', CreateProduct)

However, when running my test, nyc/istanbul will complain that line 9 is an Uncovered Line (in my example, it is the next(err) function), how do I go about simulating the error in my example?

score 2 · Accepted Answer · answered Sep 10 '17 at 05:55

2

The easier to go is to create a validation mechanism for your ProductModel, and when you create the product with invalid data throw some validation errors.

And in your mocha you will send an invalid product body and it will catch your next.

answered Sep 10 '17 at 05:55

Alexandru Olaru

6,842
6
27
53

I accept your answer as it is the shortest and easiest solution that solved my particular case. Thanks heaps! – borislemke Sep 10 '17 at 07:56

score 2 · Answer 2 · answered Sep 10 '17 at 06:13

Two of the easiest possible ways of doing this are as follows:

1) Admit that controllers can not be unit tested, and because they can not be unit tested, they will be a part of your integration tests, and because that is true, you are going to move as much unit testable code out of them as physically possible, and limit them to doing little more than composing pieces of code which are able to be tested. This would be fine; an Express controller is sort of like a main method into your application, from the view of an individual request, anyway, so having it mix together the hard concepts to decide what gets built is okay, as long as the main isn't doing the heavy lifting, but rather instantiating and running things which are doing the lifting.

2) Compose your functions so that they all receive all of the props that they require, to do their jobs, and moreso, they nearly always receive them from other files (not the file they're defined in), unless the assignment is just as a default value.

In the case of a controller, if you wanted the controller to be unit-testable, you would preconfigure it to accept a ProductModel to use (or a function to use) rather than assuming you are going to pull in the real model.

export const CreateProduct = (ProductModel) => async (req, res, next) => {
  const productData = req.body
  try {
    const product = await ProductModel.create(productData)
    res.send(product)
  } catch (err) {
    next(err)
  }
}



import { CreateProduct } from './create_product'
import { ConfigureProductModel } from './somewhere_else'

export const ProductRouter = express.Router()
ProductRouter.post('/', CreateProduct(ConfigureProductModel(database)))

Now to test that, you can easily create a CreateProduct where you pass in a fake ProductModel. And if you use the example, there of ConfigureProductModel as a factory, you can test it by passing it a fake db instance (if you do, indeed have that level of control).

And personally, like I said, as a controller, I want to remove as much control as possible, so I'd probably take most of the imperative code away.

const CreateProduct = ProductModel => (req, res, next) =>
  ProductModel.create(req.body)
    .then(product => res.send(product))
    .catch(next);

Thank you very much for your explanation. I've chosen to accept Alexandru's answer as it directly answers my particular case. However, I am glad you took the time to write this awesome explanation. This has helped me a lot on rethinking about how I structure my Express app. — borislemke, Sep 10 '17 at 08:01
@borislemke Fair, and I’m not all that worried about it, for my sake. Just keep in mind that you currently require live internet and live DB connections, in order to run tests. Many people in many systems have had their credit cards charged, in such systems, and many more couldn’t do any work while not attached to a network. These suggestions aren’t just for the sake of better coverage, easier testing or cleaner code; those are just some of the side-effects. — Norguard, Sep 10 '17 at 08:12

Simulating request error with async function

2 Answers2