Why testing APIs matters in Express - Visual Breakdown

Concept Flow - Why testing APIs matters

Write API code

↓

Create tests for API

↓

Run tests

↓

Tests pass?

No→Fix bugs

↓

Re-run tests

↓

API works as expected

↓

Deploy confidently

This flow shows how writing and running tests helps find bugs early, fix them, and ensure the API works before deployment.

Execution Sample

Express

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

test('GET /api returns 200', async () => {
  const response = await request(app).get('/api');
  expect(response.statusCode).toBe(200);
});

This test checks if the API endpoint '/api' responds with status code 200, meaning it works correctly.

Execution Table

Step	Action	Evaluation	Result
1	Send GET request to /api	Request sent	Response received
2	Check response statusCode	statusCode == 200?	True
3	Test passes	No errors	Success
4	End test	All checks done	Test complete

💡 Test ends after confirming API returns status 200 successfully

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
response.statusCode	undefined	undefined	200	200
test result	undefined	undefined	undefined	pass

Key Moments - 2 Insights

Why do we check the response status code in the test?

Checking the status code confirms the API endpoint responds correctly; as shown in execution_table step 2, it ensures the API works as expected.

What happens if the test fails?

If the test fails (status code not 200), you fix bugs and re-run tests until they pass, as shown in the concept_flow loop.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response statusCode at Step 2?

A 500

B 404

C 200

D undefined

💡 Hint

Check the 'Evaluation' and 'Result' columns at Step 2 in execution_table

At which step does the test confirm success?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look for the step where 'Test passes' and 'Success' appear in execution_table

If the API returned status 500 instead of 200, what would change in the execution_table?

A Step 1 would not send the request

B Step 2 evaluation would be false and test would fail

C Step 3 would still show success

D Test would end at Step 4 normally

💡 Hint

Refer to Step 2 where statusCode is checked against 200 in execution_table

Concept Snapshot

Why testing APIs matters:
- Write tests to check API responses
- Run tests to catch bugs early
- Fix bugs if tests fail
- Passing tests mean API works
- Deploy with confidence knowing API is tested

Full Transcript

Testing APIs is important because it helps catch problems early before users see them. We write tests that send requests to API endpoints and check responses, like status codes. If tests pass, it means the API works as expected. If tests fail, we fix bugs and try again. This process ensures the API is reliable and ready for deployment.

Practice

1. Why is testing APIs important in Express applications?

easy

A. It automatically updates the API documentation.

B. It makes the app run faster on the server.

C. It helps find and fix problems early before users see them.

D. It reduces the size of the API code.

Solution

1. Step 1: Understand the purpose of API testing

   Testing APIs helps catch bugs and errors early in development.

2. Step 2: Identify the benefit of early problem detection

   Finding problems early prevents issues from reaching users and causing failures.

3. Final Answer:

   It helps find and fix problems early before users see them. -> Option C

4. Quick Check:

   API testing = early bug detection [OK]

Hint: Testing finds bugs early to avoid user issues [OK]

Common Mistakes:

• Thinking testing speeds up server runtime
• Confusing testing with documentation generation
• Believing testing reduces code size

2. Which of the following is the correct way to write a simple test for an Express API endpoint using a testing library like Jest and Supertest?

easy

A. app.get('/api').expect(200);

B. request(app).get('/api').expect(200).end(done);

C. request('/api').get(app).expect(200);

D. expect(request(app).get('/api')).toBe(200);

Solution

1. Step 1: Recognize the correct testing syntax

   Using Supertest, you call request(app).get('/api') to test the endpoint.

2. Step 2: Confirm chaining with expect and end

   The correct pattern chains .expect(200) and .end(done) to complete the test.

3. Final Answer:

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

4. Quick Check:

   Supertest syntax = request(app).get().expect() [OK]

Hint: Supertest uses request(app).get(url).expect(status) [OK]

Common Mistakes:

• Calling expect directly on app.get instead of request
• Swapping app and URL in request call
• Using expect incorrectly without chaining

3. Consider this Express API test snippet using Jest and Supertest:

test('GET /users returns 200 and JSON', async () => {
  const response = await request(app).get('/users');
  expect(response.status).toBe(200);
  expect(response.headers['content-type']).toMatch(/json/);
});

What will happen if the API returns status 404 instead of 200?

medium

A. The test will fail because the status is not 200.

B. The test will pass because content-type is checked.

C. The test will throw a syntax error.

D. The test will ignore the status and pass.

Solution

1. Step 1: Analyze the status check in the test

   The test expects response.status to be exactly 200.

2. Step 2: Understand test behavior on mismatch

   If the API returns 404, the expect(response.status).toBe(200) assertion fails and the test fails.

3. Final Answer:

   The test will fail because the status is not 200. -> Option A

4. Quick Check:

   Status check fails test if not 200 [OK]

Hint: Expect status 200; else test fails [OK]

Common Mistakes:

• Assuming test passes if content-type matches
• Thinking 404 triggers syntax error
• Believing test ignores status mismatch

4. You wrote this Express API test but it always times out:

test('POST /login returns 200', (done) => {
  request(app)
    .post('/login')
    .send({ username: 'user', password: 'pass' })
    .expect(200);
});

What is the main reason for the timeout?

medium

A. Missing call to done() to signal test completion.

B. Incorrect HTTP method used for /login endpoint.

C. The .send() method is not supported in Supertest.

D. The test expects 200 but server returns 500.

Solution

1. Step 1: Check test callback usage

   The test uses done callback but never calls done(), so Jest waits forever.

2. Step 2: Understand how to end async tests

   Calling done() inside .end() or returning a promise is needed to finish the test.

3. Final Answer:

   Missing call to done() to signal test completion. -> Option A

4. Quick Check:

   Call done() to end async test [OK]

Hint: Always call done() or return promise in async tests [OK]

Common Mistakes:

• Forgetting to call done() in callback tests
• Assuming .send() is unsupported
• Guessing wrong HTTP method without checking

5. You want to ensure your Express API handles errors correctly. Which testing approach best helps catch unexpected server errors early?

hard

A. Skip testing and rely on console logs for errors.

B. Manually test the API endpoints once after deployment.

C. Only test the API when users report bugs.

D. Write automated tests that simulate invalid inputs and check for 4xx or 5xx responses.

Solution

1. Step 1: Identify best practice for error handling tests

   Automated tests simulating invalid inputs help verify API returns proper error codes.

2. Step 2: Understand benefits of early automated error detection

   This approach finds bugs before deployment and prevents user impact.

3. Final Answer:

   Write automated tests that simulate invalid inputs and check for 4xx or 5xx responses. -> Option D

4. Quick Check:

   Automated error tests catch bugs early [OK]

Hint: Test invalid inputs automatically to catch errors early [OK]

Common Mistakes:

• Relying only on manual or post-deployment testing
• Ignoring error cases in tests
• Depending on logs instead of tests