Capstone — Testing a Real API Across All Four Tools

API Testing & Tooling — Capstone: Testing a Real API Across All Four Tools

API Testing & Tooling

Chapter 9 · Capstone: Testing a Real API Across All Four Tools

🏁 Capstone: Testing a Real API Across All Four Tools

Chapter 1 previewed the same request across all four tool categories. This capstone finishes what that preview started — a small, real Task API (login, create, get, delete), tested end to end with Postman, a VS Code .http file, cURL scripts, and the browser, then a subset of it wired into CI.

The API We're Testing

Endpoint	Purpose
`POST /login`	Returns a bearer token
`POST /tasks`	Creates a task, returns its id
`GET /tasks/:id`	Fetches one task
`DELETE /tasks/:id`	Deletes a task

Step 1: Postman (Chapters 2–4)

A collection with an Auth folder (Login) and a Tasks folder (Create/Get/Delete), a baseUrl environment variable, and the Login request's Test script automatically extracting the token:

pm.test("Login succeeded", () => pm.response.to.have.status(200));
pm.environment.set("authToken", pm.response.json().token);

Create Task's Test script does the same for the new task's id, so Get/Delete Task can reference {{taskId}} directly — the exact chaining pattern from Chapter 3, automated per Chapter 4.

Step 2: VS Code .http File (Chapter 5)

The same flow, committed to the repo as plain text:

# @name login
POST {{baseUrl}}/login
Content-Type: application/json

{ "email": "dana@example.com", "password": "..." }

###

# @name createTask
POST {{baseUrl}}/tasks
Authorization: Bearer {{login.response.body.$.token}}
Content-Type: application/json

{ "title": "Write capstone notes" }

###

GET {{baseUrl}}/tasks/{{createTask.response.body.$.id}}
Authorization: Bearer {{login.response.body.$.token}}

Step 3: cURL Scripts (Chapters 6–7)

A small script suite, reading secrets from the environment, never hardcoding them, chaining values via jq:

#!/bin/bash
# login.sh — logs in, exports TOKEN for the other scripts
TOKEN=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d "{\"email\":\"$EMAIL\",\"password\":\"$PASSWORD\"}" \
  | jq -r '.token')
export TOKEN

# create-task.sh — creates a task, prints its id
curl -s -X POST "$BASE_URL/tasks" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Write capstone notes"}' \
  | jq -r '.id'

Step 4: Browser Testing (Chapter 8)

Since creating a task needs a JSON body and a bearer token, a plain form can't do it — this needs the fetch() console trick:

fetch("https://api.example.com/tasks", {
  method: "POST",
  headers: { "Authorization": "Bearer " + token, "Content-Type": "application/json" },
  body: JSON.stringify({ title: "Write capstone notes" })
}).then(r => r.json()).then(console.log);

Then opening the Network tab, finding that request, and using "Copy as cURL" — comparing the exported command against Step 3's own hand-written script is a genuine way to confirm both are sending the identical request.

Step 5: Automating a Subset in CI

Not everything from Steps 1–4 belongs in CI. Browser testing (Step 4) needs a real interactive browser session and isn't meant to run unattended; Postman's collection, run headlessly through Newman (Chapter 4), and the cURL scripts (Step 3) both can run in a CI job with no human present — these are the two candidates for automation.

# CI step — fails the build if any assertion fails (pipelines1-4)
newman run task-api.postman_collection.json -e ci.postman_environment.json

Tool	Role in This Capstone
Postman	Building and organizing the flow interactively; automated in CI via Newman
.http file	The same flow, committed and reviewable in the repo
cURL scripts	Terminal-native, reusable, scriptable — usable in CI too
Browser (fetch/Network)	Manual exploration and request verification — not run in CI

💻 Coding Challenges

Challenge 1: Add the Delete Step

Extend Step 3's cURL scripts with a delete-task.sh that deletes the task created by create-task.sh, using the same $TOKEN environment variable.

Goal: Practice extending an existing reusable script suite consistently, rather than writing an unrelated one-off command.

→ Solution

Challenge 2: Decide What Belongs in CI

Of this capstone's four tools, which should run in an automated CI pipeline, and which shouldn't? Justify each answer using this chapter's Step 5 reasoning.

Goal: Practice applying the manual-vs-automated distinction from Chapter 1 to a concrete four-tool scenario.

→ Solution

Challenge 3: Trace a Bug Across Tools

A teammate reports "Create Task fails in our .http file but works fine in Postman." Using this course's material, list two genuinely different things worth checking before assuming it's an API bug.

Goal: Practice using multiple tools to isolate whether a discrepancy is caused by the tool's own state (e.g. stale variables) rather than the API itself.

→ Solution

⚠️ Gotcha: Four Tools Means Four Separate Copies of "Current State"

Postman's environment, the .http file's http-client.env.json, and the shell's exported $TOKEN/$BASE_URL are three independent stores of the same conceptual values — nothing keeps them automatically in sync. A token refreshed in Postman doesn't update the shell's $TOKEN; a baseUrl changed in the .http environment file doesn't touch Postman's. This is easy to forget once several tools are in play side by side, and it produces a specific, confusing symptom: the exact same request behaving differently depending on which tool ran it — not because the API changed, but because one tool's copy of "current state" quietly drifted from another's. When two tools disagree, checking whether their variables actually still match is often the fastest first step, before suspecting the API itself.

🎉 Course Complete

That's the full API Testing & Tooling course — from why testing matters and the tools landscape, through Postman, VS Code, cURL, and the browser, to a real API tested across all four and a subset automated in CI. Together with API Types & Design, this completes the first two courses in the site's APIs & Integration area; gRPC remains next on the bucket list.