Chapter 1.5: Testing an API with Postman
Study time: 50 minutes
1. Why Test an API? Pre-launch Check
Imagine: before launching a rocket, engineers conduct test system activations. Skip the check, and the mission could fail!
API testing is your control test:
-
✅ Check the functionality of the "docking ports"
-
🛡️ Detect vulnerabilities before live use
-
📊 Ensure that data is transmitted without distortion
💡 Space analogy: Postman is like a test console at the MCC for simulating all scenarios: "What if we request data about a non-existent planet? Can the server handle 1000 requests/sec?"
2. Postman: The "Mission Control Center" for APIs
Features:
-
📡 Sending any HTTP requests (GET, POST, PUT, DELETE)
-
🔍 Analyzing responses (status codes, headers, JSON body)
-
🧪 Writing automated tests (JavaScript)
-
🌐 Working with environment variables (test vs. production)
3. First Launch: Testing the Planets API
Step 1: Create a request
-
Open Postman → New → Request
-
Enter the URL:
https://api.spacexdata.com/v4/rockets
-
Select the method: GET
Step 2: Send the "signal"
Step 3: Analyze the telemetry:
- Status: 200 OK
- Response body (JSON): a list of rockets with parameters
[
{
"name": "Falcon 1",
"type": "rocket",
"active": false,
"stages": 2,
"id": "5e9d0d95eda69955f709d1eb"
},
{
"name": "Falcon 9",
"type": "rocket",
"active": true,
"id": "5e9d0d95eda69973a809d1ec"
}
]
4. Diagram: Postman Components
[Workspace]
├── "Params" tab (Query parameters)
├── "Headers" tab (Headers)
├── "Body" tab (Request body for POST/PUT)
├── "Tests" tab (Scripts for checks)
└── Response panel (Status, Time, Size, Body)
5. Creating a Complex Scenario: Mission Launch
Test: Adding a new planet to the catalog
-
Method: POST
-
URL:
https://jsonplaceholder.typicode.com/posts
(example) -
In Headers:
- In Body (raw → JSON):
Automated check in Tests:
// Status check
pm.test("Post created successfully", () => {
pm.response.to.have.status(201);
});
// Checking the structure and data of the response
pm.test("Response contains the new post data", () => {
const response = pm.response.json();
pm.expect(response).to.have.property("id"); // Check that the server has assigned an ID
pm.expect(response.title).to.eql("New Exoplanet Found");
});
6. Environment Variables: Earth vs. Mars
How to test on different servers (test/production)?
- Create environments:
Local
→http://localhost:3000
-
Production
→https://api.nasa.gov
-
Use variables in requests:
⚠️ Important! Never test
DELETE
on a production server!
7. Collections: A Library of Space Missions
Group requests:
Advantages:- 🚀 Run all tests with one button
- 📤 Export/import configurations
- 👨🚀 Team collaboration
8. Automation: Regular Satellite Checks
Set up API monitoring via Postman:
-
Schedule → Every 2 hours
-
Tests:
-
Notifications to Slack/email on failure
Quiz for reinforcement
🚀 Chapter summary: Postman is your universal "control panel" for API testing. With it you will: - Check the operation of "onboard systems" before launch - Create a library of test scenarios - Automate the monitoring of space services
📌 Practical task:
- Install Postman
- Create a request to the SpaceX API:
GET https://api.spacexdata.com/v4/launches/latest
- Write a test that checks that:
- The response status is
200
- The
name
field contains the word "Falcon"- The response time is < 500 ms
Congratulations on completing Chapter 1!
You have mastered the basics of working with APIs. In the following chapters, we will build our own "spaceship" - a web application that uses space APIs!
🌌 Additional resources: