Middleware testing strategies in Express - Step-by-Step Execution

Concept Flow - Middleware testing strategies

Write Middleware Function

↓

Create Mock Request & Response

↓

Call Middleware with Mocks

↓

Check Middleware Behavior

↓

Assert Expected Outcome

↓

Done

This flow shows how to test middleware by creating fake requests and responses, running the middleware, and checking results.

Execution Sample

Express

const req = { headers: { authorization: 'token' } };
const res = {};
const next = jest.fn();
middleware(req, res, next);
expect(next).toHaveBeenCalled();

This code tests a middleware by simulating a request, response, and next function, then checks if next() was called.

Execution Table

Step	Action	Input State	Middleware Behavior	Output State	Test Check
1	Create mock req	No req	Prepare req with headers.authorization='token'	req.headers.authorization='token'	N/A
2	Create mock res	No res	Prepare empty res object	res={}	N/A
3	Create mock next	No next	Create spy function to track calls	next=spy function	N/A
4	Call middleware(req,res,next)	req.headers.authorization='token', res={}, next=spy	Middleware checks authorization header, calls next()	next called once	N/A
5	Assert next called	next called once	Test framework verifies next() was called	Test passes	next() was called as expected
6	End	Test complete	No more actions	Test ends	Test successful

💡 Middleware calls next(), test confirms next() was called, so test ends successfully.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
req	undefined	{ headers: { authorization: 'token' } }	{ headers: { authorization: 'token' } }	{ headers: { authorization: 'token' } }	{ headers: { authorization: 'token' } }	{ headers: { authorization: 'token' } }
res	undefined	undefined	{}	{}	{}	{}
next	undefined	undefined	undefined	spy function	spy function (called once)	spy function (called once)

Key Moments - 3 Insights

Why do we create mock request and response objects instead of real ones?

Because real HTTP requests and responses are complex and slow to create, mocks let us test middleware quickly and control inputs precisely, as shown in execution_table steps 1 and 2.

How do we know if the middleware behaved correctly?

We check if the middleware called next() or modified res as expected. In the execution_table step 5, the test asserts next() was called, confirming correct behavior.

What if middleware sends a response and does not call next()?

Then the test should check if res methods like res.send were called and next() was not called. This differs from the example where next() is expected, as seen in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of req.headers.authorization after Step 1?

A null

B 'token'

C undefined

D 'authorization'

💡 Hint

Check the 'Output State' column in Step 1 of execution_table.

At which step does the middleware call the next() function?

A Step 2

B Step 5

C Step 4

D Step 3

💡 Hint

Look at the 'Middleware Behavior' column to see when next() is called.

If the middleware did not call next(), which test check would fail according to the execution_table?

A Step 5 assertion

B Step 4 behavior

C Step 1 assertion

D Step 3 mock creation

💡 Hint

Step 5 asserts next() was called; if not, this assertion fails.

Concept Snapshot

Middleware testing steps:
1. Create mock req, res, next.
2. Call middleware(req, res, next).
3. Check if middleware calls next() or modifies res.
4. Assert expected behavior with test framework.
Use mocks to isolate middleware logic from real HTTP.
This ensures fast, reliable tests.

Full Transcript

Middleware testing in Express involves creating fake request and response objects and a spy function for next. We run the middleware with these mocks and check if it behaves as expected, such as calling next() or sending a response. This method isolates middleware logic from real network calls, making tests fast and reliable. The execution table shows each step from mock creation to assertion. Key points include why mocks are used, how to verify middleware behavior, and handling cases where middleware ends the response without calling next.

Practice

1. What is the main purpose of testing middleware in an Express app?

easy

A. To verify that middleware correctly processes requests and responses

B. To check the database connection speed

C. To test the frontend user interface

D. To measure server hardware performance

Solution

1. Step 1: Understand middleware role

   Middleware functions handle requests and responses in Express apps.

2. Step 2: Identify testing focus

   Testing middleware ensures it processes requests and responses correctly.

3. Final Answer:

   To verify that middleware correctly processes requests and responses -> Option A

4. Quick Check:

   Middleware testing = request/response handling [OK]

Hint: Middleware tests check request and response flow [OK]

Common Mistakes:

• Confusing middleware testing with UI testing
• Testing unrelated server hardware
• Ignoring request and response handling

2. Which syntax correctly uses a testing library to simulate a request to Express middleware?

easy

A. request(app).get('/path').expect(200, done)

B. app.request('/path').send(200)

C. middleware.test('/path').status(200)

D. express.test(app).get('/path').check(200)

Solution

1. Step 1: Recognize common testing syntax

   Using 'request(app).get(path).expect(status, done)' is standard with supertest library.

2. Step 2: Compare options

   Only request(app).get('/path').expect(200, done) matches valid syntax for simulating requests in Express tests.

3. Final Answer:

   request(app).get('/path').expect(200, done) -> Option A

4. Quick Check:

   Simulate request = request(app).get() [OK]

Hint: Use request(app).get() to simulate Express requests [OK]

Common Mistakes:

• Using non-existent methods like app.request()
• Confusing middleware with app methods
• Incorrect chaining of test methods

3. Given this middleware test snippet, what will be the output if the middleware calls next() without error?

app.use((req, res, next) => {
  if (req.query.fail) return next(new Error('Fail'));
  res.status(200).send('Success');
});

request(app).get('/?fail=true').expect(500, done);

medium

A. The test passes with status 200

B. The test fails because status 200 is sent

C. The test throws a syntax error

D. The test passes because error triggers 500 status

Solution

1. Step 1: Analyze middleware behavior on fail query

   If req.query.fail is true, middleware calls next() with an error, triggering Express error handling.

2. Step 2: Understand test expectation

   The test expects status 500, which matches Express default error response status.

3. Final Answer:

   The test passes because error triggers 500 status -> Option D

4. Quick Check:

   Error passed to next() = 500 response [OK]

Hint: Error in next() triggers 500 status by default [OK]

Common Mistakes:

• Assuming next() without error sends 200
• Ignoring error passed to next()
• Confusing status codes for errors

4. You wrote this test but it always times out. What is the likely error?

app.use((req, res, next) => {
  if (!req.headers.auth) return res.status(401);
  next();
});

request(app).get('/').expect(401, done);

medium

A. next() is called twice causing conflict

B. Missing res.send() causes response never to finish

C. Incorrect HTTP method used in request

D. Middleware does not check headers properly

Solution

1. Step 1: Check middleware response on missing auth

   res.status(401) sets status but does not end response without res.send() or res.end().

2. Step 2: Understand test timeout cause

   Without ending response, test waits indefinitely causing timeout.

3. Final Answer:

   Missing res.send() causes response never to finish -> Option B

4. Quick Check:

   res.status() alone doesn't end response [OK]

Hint: Always end response with res.send() or res.end() [OK]

Common Mistakes:

• Assuming res.status() ends response
• Calling next() after sending response
• Using wrong HTTP method in test

5. You want to test middleware that conditionally modifies the request object and passes control. Which approach best ensures both modification and flow are tested?

hard

A. Test middleware by calling it without any request data

B. Only check the final response status code

C. Use a mock request object and spy on next() to confirm it was called

D. Skip testing and rely on manual checks

Solution

1. Step 1: Understand middleware modifies request and calls next()

   Testing must confirm request changes and that next() is called to continue flow.

2. Step 2: Choose testing approach

   Using a mock request and spying on next() lets you verify both modification and flow control.

3. Final Answer:

   Use a mock request object and spy on next() to confirm it was called -> Option C

4. Quick Check:

   Mock request + spy next() = full middleware test [OK]

Hint: Spy next() and check request changes for full test [OK]

Common Mistakes:

• Ignoring next() call verification
• Testing only response status
• Not providing request data in tests