Creating API Test Cases from Beginner to Advanced

Part 5A — Creating API Test Cases: Beginner to Intermediate

Published by Way2Testing | Category: API Testing Strategy | Estimated Read Time: 14 min

Welcome to Part 5A of our master API testing curriculum! Writing robust API test cases is what separates basic functional checks from bulletproof QA automation. In this guide, we explore how to design structured test scenarios, apply test design techniques like boundary value analysis, and validate positive and negative behaviors.

Table of Contents (Part 5A)

1. How to Write Your First API Test Case
2. API Test Case Design with Examples
3. Positive vs Negative API Test Scenarios
4. Test Cases for a GET API
5. Test Cases for a POST API
6. Test Cases for PUT, PATCH & DELETE APIs
7. Boundary Value Testing for APIs
8. Equivalence Partitioning in API Testing
9. Required and Optional Field Validation
10. Invalid Data Type and Missing Field Testing

Figure 1: Comprehensive lifecycle from API contract inspection to boundary and validation testing.

1. How to Write Your First API Test Case & 2. Test Case Design

An API test case follows the structured verification of Input Request → Endpoint Interaction → Expected Response. Before writing automation scripts in Rest Assured or Postman, design your test cases using a structured template containing:

• Test ID & Title: Clear description of what is being tested.
• HTTP Method & Endpoint URL: Target route.
• Headers & Payload: Required content-type, authorization tokens, and request body.
• Expected Result: Status code, specific response body keys, and performance SLAs.

3. Positive vs. Negative API Test Scenarios

Effective test coverage requires both success and failure path validation:

• Positive Scenarios: Valid inputs, correct permissions, and well-formed payloads yielding 2xx success codes.
• Negative Scenarios: Malformed JSON, incorrect authentication, missing mandatory parameters, or unauthorized actions yielding 4xx or 5xx error codes.

4. GET, 5. POST, and 6. PUT/PATCH/DELETE API Test Scenarios

Different HTTP methods mandate distinct verification checklists:

HTTP Method	Positive Test Scenarios	Negative Test Scenarios
GET	Retrieve all records; fetch item by valid ID (200 OK).	Request non-existent ID (404); invalid URL format (400).
POST	Create resource with valid mandatory/optional fields (201 Created).	Duplicate entry (409 Conflict); missing mandatory fields (400 Bad Request).
PUT / PATCH	Update entire object (PUT) or specific attributes (PATCH) successfully.	Update non-existent resource ID (404 Not Found).
DELETE	Successfully remove an active resource (200 OK or 204 No Content).	Delete already deleted or non-existent ID (404 Not Found).

7. Boundary Value Testing (BVA) & 8. Equivalence Partitioning

Black-box test design techniques apply directly to API query parameters and payload fields:

• Boundary Value Analysis (BVA): If an API accepts an age between 18 and 60, test boundaries 17, 18, 19 and 59, 60, 61.
• Equivalence Partitioning: Divide input data into valid and invalid partitions. For example, test one valid status string (e.g., "ACTIVE") and one invalid status string (e.g., "UNKNOWN").

9. Required vs. Optional Fields & 10. Invalid Data Type Testing

Payload validation test cases must confirm server resilience against data discrepancies:

• Required Field Omission: Omitting a mandatory field (e.g., email) should return a validation error message with status 400 Bad Request.
• Invalid Data Types: Sending a string value (e.g., "twenty") where an integer (age: 20) is expected must be properly rejected by the schema parser.

© Way2Testing — Empowering Quality Assurance Engineers Worldwide.