Testing GET endpoints in Express - Step-by-Step Execution

Concept Flow - Testing GET endpoints

Start Test

↓

Send GET Request

↓

Server Receives Request

↓

Server Processes Request

↓

Server Sends Response

↓

Test Receives Response

↓

Check Status & Body

↓

Pass or Fail Test

↓

End Test

The test sends a GET request to the server, waits for the response, then checks if the response status and body match expectations.

Execution Sample

Express

import request from 'supertest';
import app from './app';

test('GET /hello returns 200 and greeting', async () => {
  const res = await request(app).get('/hello');
  expect(res.status).toBe(200);
  expect(res.text).toBe('Hello World!');
});

This test sends a GET request to '/hello' and checks if the response status is 200 and the body text is 'Hello World!'.

Execution Table

Step	Action	Request Sent	Server Response	Test Check	Result
1	Send GET request to /hello	GET /hello	Waiting...	Waiting...	Pending
2	Server receives request	GET /hello	Processing	Waiting...	Pending
3	Server processes and sends response	GET /hello	Status: 200, Body: 'Hello World!'	Waiting...	Pending
4	Test receives response	GET /hello	Status: 200, Body: 'Hello World!'	Check status == 200	Pass
5	Test checks response body	GET /hello	Status: 200, Body: 'Hello World!'	Check body == 'Hello World!'	Pass
6	Test ends	GET /hello	Status: 200, Body: 'Hello World!'	All checks passed	Test Passed

💡 Test ends after all assertions pass confirming GET endpoint works as expected.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
res.status	undefined	undefined	200	200	200
res.text	undefined	undefined	'Hello World!'	'Hello World!'	'Hello World!'
testResult	undefined	Pending	Pending	Pass	Test Passed

Key Moments - 3 Insights

Why does the test wait after sending the GET request before checking the response?

Because the server needs time to process the request and send back a response. The test waits for the response before checking status and body, as shown in steps 1 to 4 in the execution_table.

What happens if the response status is not 200?

The test will fail at the status check step (step 4). The test expects 200, so any other status causes a failure, stopping further checks.

Why do we check both status and body in the test?

Checking status ensures the request succeeded, and checking body confirms the server returned the correct content. Both are needed to fully verify the GET endpoint works, as shown in steps 4 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response status at step 3?

A 500

B 404

C 200

D undefined

💡 Hint

Check the 'Server Response' column at step 3 in the execution_table.

At which step does the test check the response body?

A Step 2

B Step 5

C Step 4

D Step 6

💡 Hint

Look at the 'Test Check' column in the execution_table for the step checking body.

If the server responded with status 404, what would happen in the test?

A Test fails at status check

B Test skips status check

C Test passes anyway

D Test passes but body check fails

💡 Hint

Refer to the key_moments about what happens if status is not 200.

Concept Snapshot

Testing GET endpoints in Express:
- Use a test tool like supertest to send GET requests.
- Await the server response asynchronously.
- Check response status code (e.g., 200).
- Check response body content.
- Pass test only if all checks succeed.

Full Transcript

This visual execution shows how to test GET endpoints in Express using a test framework and supertest. The test sends a GET request to the server, waits for the response, then checks the status code and response body. The execution table traces each step from sending the request, server processing, receiving the response, to checking assertions. Variables like response status and text update as the test progresses. Key moments clarify why waiting for the response is necessary and why both status and body are checked. The quiz questions reinforce understanding by referencing the execution steps and outcomes. This approach helps beginners see exactly how testing GET endpoints works step-by-step.

Practice

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

easy

A. To verify the server returns the correct data and status code

B. To check if the server can handle POST requests

C. To test database connection speed

D. To validate CSS styles on the page

Solution

1. Step 1: Understand GET endpoint testing

   Testing GET endpoints means checking if the server responds correctly when a client asks for data.

2. Step 2: Identify the goal of testing

   The goal is to confirm the server sends the right data and proper HTTP status code (like 200 for success).

3. Final Answer:

   To verify the server returns the correct data and status code -> Option A

4. Quick Check:

   Testing GET endpoints = verify data and status [OK]

Hint: GET endpoint tests check response data and status code [OK]

Common Mistakes:

• Confusing GET with POST request testing
• Testing unrelated features like CSS or database speed
• Ignoring status codes in tests

2. Which of the following is the correct way to start a test for a GET endpoint using supertest with Express?

easy

A. app.get('/path').send(200);

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

C. supertest.get('/path').expect(200);

D. request.get(app, '/path').expect(200);

Solution

1. Step 1: Recall supertest syntax

   Supertest uses request(app).get('/path') to simulate a GET request to the Express app.

2. Step 2: Check the correct chaining

   Chaining .expect(200, done) checks the status code and signals test completion.

3. Final Answer:

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

4. Quick Check:

   supertest GET syntax = request(app).get(path).expect(status) [OK]

Hint: Use request(app).get(path).expect(status, done) for GET tests [OK]

Common Mistakes:

• Calling app.get() instead of request(app).get()
• Missing the done callback in async tests
• Incorrect method chaining order

3. Given this Express GET endpoint and test code, what will the test output?

const express = require('express');
const app = express();
app.get('/hello', (req, res) => res.json({ message: 'Hi!' }));

const request = require('supertest');

test('GET /hello returns message', async () => {
  const response = await request(app).get('/hello');
  return response.body.message;
});

medium

A. "Hi!"

B. undefined

C. Error: No response

D. "hello"

Solution

1. Step 1: Analyze the endpoint response

   The GET /hello endpoint sends JSON { message: 'Hi!' } as response.

2. Step 2: Check the test return value

   The test awaits the GET request and returns response.body.message, which is 'Hi!'.

3. Final Answer:

   "Hi!" -> Option A

4. Quick Check:

   GET /hello returns message = "Hi!" [OK]

Hint: Response body message matches endpoint JSON key [OK]

Common Mistakes:

• Expecting response.body instead of response.body.message
• Forgetting to await the request
• Assuming string 'hello' instead of 'Hi!'

4. Identify the error in this test code for an Express GET endpoint:

const request = require('supertest');
const app = require('./app');

test('GET /users returns 200', () => {
  request(app)
    .get('/users')
    .expect(200);
});

medium

A. Missing import of Express

B. Incorrect HTTP method used

C. Missing return or await to handle async test

D. Wrong path '/users' does not exist

Solution

1. Step 1: Check async test handling

   The test function is async but does not return or await the request promise, so Jest won't wait for it.

2. Step 2: Confirm correct fix

   Adding return before request(...) or making the test async and awaiting fixes the issue.

3. Final Answer:

   Missing return or await to handle async test -> Option C

4. Quick Check:

   Async test needs return or await [OK]

Hint: Always return or await supertest calls in tests [OK]

Common Mistakes:

• Not returning or awaiting async calls in tests
• Assuming path or method is wrong without checking
• Confusing import errors with test async errors

5. You want to test an Express GET endpoint that returns a list of users, but only those with active status true. Which test code correctly checks this filtering?

app.get('/active-users', (req, res) => {
  const users = [
    { id: 1, active: true },
    { id: 2, active: false },
    { id: 3, active: true }
  ];
  res.json(users.filter(u => u.active));
});

// Test code options:
A) await request(app).get('/active-users').expect(200).expect(res => {
  if (!res.body.every(u => u.active)) throw new Error('Inactive user found');
});

B) await request(app).get('/active-users').expect(200).expect(res => {
  if (res.body.length !== 3) throw new Error('Wrong number of users');
});

C) await request(app).get('/active-users').expect(404);

D) await request(app).get('/active-users').expect(200).expect(res => {
  if (!res.body.some(u => u.active === false)) throw new Error('Inactive user found');
});

hard

A. Incorrectly throws error when no inactive users found

B. Incorrectly expects all users, including inactive

C. Wrong status code expectation

D. Checks for inactive users but throws error if found

Solution

1. Step 1: Understand endpoint filtering

   The endpoint returns only users with active: true, so no inactive users should appear.

2. Step 2: Analyze test options

   Checks for inactive users but throws error if found uses every(u => u.active) and throws if any inactive, correctly verifying the filter.
   Incorrectly expects all users, including inactive expects length !== 3 (wrong, it's 2).
   Wrong status code expectation expects 404 (wrong).
   Incorrectly throws error when no inactive users found incorrectly throws error when no inactive users found.

3. Step 3: Verify A logic

   !every(u => u.active) detects any inactive user, matching the requirement.

4. Final Answer:

   Checks for inactive users but throws error if found -> Option D

5. Quick Check:

   Test filters out inactive users = no inactive found [OK]

Hint: Check response has no inactive users with some() or every() [OK]

Common Mistakes:

• Expecting all users instead of filtered active only
• Using wrong status code in test
• Confusing every() and some() logic in tests