Middleware testing strategies in Express - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a simple Express middleware function that logs the request method.

Express

function logger(req, res, [1]) {
  console.log(req.method);
  next();
}

Drag options to blanks, or click blank then click option'

Ahandle

Bdone

Ccallback

Dnext

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect parameter names like 'done' or 'callback' instead of 'next'.

Forgetting to call the next function.

The middleware function must include next as the third parameter to pass control to the next middleware.

2fill in blank

medium

Complete the code to test an Express middleware that adds a property to the request object.

Express

const req = {};
const res = {};
const next = () => {};
middleware(req, res, [1]);
console.log(req.customProperty);

Drag options to blanks, or click blank then click option'

Adone

Bnext

Ccallback

Dhandle

Attempts:

3 left

💡 Hint

Common Mistakes

Passing incorrect function names instead of 'next'.

Not passing a function as the third argument.

When testing middleware, you call it with req, res, and a next function to simulate Express behavior.

3fill in blank

hard

Fix the error in the test code that checks if middleware calls next with an error.

Express

middleware(req, res, (err) => {
  if (err) {
    console.log('Error handled');
  }
  [1];
});

Drag options to blanks, or click blank then click option'

Areturn

Bthrow err

Cnext()

Dconsole.error(err)

Attempts:

3 left

💡 Hint

Common Mistakes

Calling next() inside the error handler callback.

Throwing the error instead of handling it.

Using return here stops further execution after handling the error, which is correct in this test callback.

4fill in blank

hard

Fill both blanks to create a test that verifies middleware modifies the response and calls next.

Express

const res = {
  statusCode: 200,
  [1]: function(code) {
    this.statusCode = code;
    return this;
  }
};

middleware(req, res, [2]);

Drag options to blanks, or click blank then click option'

Astatus

Bnext

Csend

Ddone

Attempts:

3 left

💡 Hint

Common Mistakes

Using send instead of status for setting status code.

Passing incorrect function names instead of next.

The res.status method sets the status code and returns res for chaining. The next function is passed to middleware to continue processing.

5fill in blank

hard

Fill all three blanks to test middleware that conditionally skips to next middleware.

Express

function testMiddleware(req, res, [1]) {
  if (!req.user) {
    [2]();
    return;
  }
  res.message = 'User found';
  [3]();
}

Drag options to blanks, or click blank then click option'

Anext

Bdone

Dcallback

Attempts:

3 left

💡 Hint

Common Mistakes

Using different names for the next function parameter and calls.

Not calling next() to continue middleware chain.

The middleware uses next to skip or continue. The first and second blanks are the next function parameter and call. The third blank is also a call to next to continue processing.

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