Consider this Express app and Jest test. What will the test output?
const express = require('express'); const request = require('supertest'); const app = express(); app.get('/hello', (req, res) => { res.status(200).send('Hello World'); }); test('GET /hello returns Hello World', async () => { const response = await request(app).get('/hello'); return response.text; });
Check the exact string sent by the Express route.
The Express route sends 'Hello World' with capital H and W. The test returns response.text which matches exactly.
Choose the correct Vitest code snippet to mock an Express middleware function.
Vitest uses vi.fn to create mocks.
Vitest's mocking function is vi.fn. Options B and D use non-existent imports. Option A uses Jest syntax, not Vitest.
Look at this Jest test for an async Express route. Why does it fail with a timeout?
const express = require('express'); const request = require('supertest'); const app = express(); app.get('/data', async (req, res) => { await new Promise(resolve => setTimeout(resolve, 100)); res.json({ success: true }); }); test('GET /data returns success true', () => { return request(app).get('/data').expect(200).expect('Content-Type', /json/).expect({ success: true }); });
Check how Jest knows when async tests finish.
The test function is not marked async and does not return the promise from supertest, so Jest ends the test early causing timeout.
Given this Express app and Vitest test, what is the final value of the variable count?
import express from 'express'; import request from 'supertest'; import { describe, it, expect } from 'vitest'; let count = 0; const app = express(); app.get('/increment', (req, res) => { count += 1; res.send('ok'); }); describe('Increment route', () => { it('increments count twice', async () => { await request(app).get('/increment'); await request(app).get('/increment'); }); });
Each GET request to /increment adds 1 to count.
The test calls the route twice, each time increasing count by 1, so final count is 2.
Vitest is often faster than Jest for testing Express apps. Why?
Think about how test runners handle processes and workers.
Vitest runs tests in the same process by default, avoiding worker startup time, making it faster especially for small test suites.