Middleware testing strategies in Express - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Express middleware test?

Consider this Express middleware that adds a custom header. What will the test output when the middleware is called?

Express

const express = require('express');
const request = require('supertest');

const app = express();

function customHeader(req, res, next) {
  res.set('X-Custom-Header', 'TestValue');
  next();
}

app.use(customHeader);
app.get('/', (req, res) => res.send('Hello'));

request(app)
  .get('/')
  .end((err, res) => {
    if (err) throw err;
    console.log(res.headers['x-custom-header']);
  });

A undefined

B Error: next() not called

C TestValue

D null

💡 Hint

Think about what the middleware does before calling next() and how headers are set.

The middleware sets the header 'X-Custom-Header' to 'TestValue' before calling next(), so the response includes this header.

❓ state_output

intermediate

What is the value of req.processed after this middleware chain?

Given these two middlewares, what will be the value of req.processed in the final handler?

Express

const express = require('express');
const app = express();

function firstMiddleware(req, res, next) {
  req.processed = 1;
  next();
}

function secondMiddleware(req, res, next) {
  req.processed += 2;
  next();
}

app.use(firstMiddleware);
app.use(secondMiddleware);

app.get('/', (req, res) => {
  res.send(String(req.processed));
});

A 1

B 2

C undefined

D 3

💡 Hint

Remember that middlewares run in order and can modify the request object.

The first middleware sets req.processed to 1, the second adds 2, so the final value is 3.

🔧 Debug

advanced

Why does this middleware test fail with a timeout?

This test for an Express middleware hangs and eventually times out. What is the cause?

Express

function faultyMiddleware(req, res, next) {
  // Missing next call
}

const express = require('express');
const request = require('supertest');
const app = express();
app.use(faultyMiddleware);

request(app)
  .get('/')
  .expect(200)
  .end((err, res) => {
    if (err) throw err;
  });

A res.send is called twice causing an error

B Middleware does not call next(), causing the test to hang

C Missing error handling middleware causes failure

D Request URL is incorrect causing no response

💡 Hint

Think about what happens if next() is not called.

The middleware never calls next(), so Express waits for next middleware or response end, causing a hang.

📝 Syntax

advanced

Which option correctly tests async middleware with error handling?

Given an async middleware that may throw an error, which test code correctly handles the error?

Express

async function asyncMiddleware(req, res, next) {
  try {
    await someAsyncOperation();
    next();
  } catch (err) {
    next(err);
  }
}

A request(app).get('/').expect(500).end((err) => { if (err) done(err); else done(); });

B request(app).get('/').then(() => done()).catch(done);

C request(app).get('/').expect(500).end(done);

D request(app).get('/').expect(200).end((err) => { if (err) done(err); else done(); });

💡 Hint

Consider how to handle errors in async middleware tests with supertest.

Option A correctly expects a 500 error and calls done properly based on error presence.

🧠 Conceptual

expert

Which testing strategy best isolates middleware behavior?

When testing Express middleware, which approach best isolates the middleware's behavior from the rest of the app?

A Test middleware only by calling it with mock req, res, and next objects

B Mount middleware on a minimal Express app and test requests against it

C Test middleware by running the full app and checking final responses

D Use integration tests that cover multiple routes and middleware chains

💡 Hint

Think about how to test middleware without interference from other parts.

Calling middleware directly with mocks isolates its logic without involving Express internals or other middleware.