API Test Design: Positive, Negative, and Edge Cases

Good API test coverage includes positive cases (valid inputs and expected success), negative cases (invalid inputs and expected errors), and edge cases (boundaries and special values). This post shows how to design them systematically.

Positive cases

Goal: Valid request → expected success (2xx) and correct response.

Examples:

• GET /users/1 with valid id → 200 and user object.
• POST /users with valid body → 201 and created user (and Location header if applicable).
• PUT /users/1 with valid body → 200 and updated user.

Design at least one positive test per endpoint and method you use; cover main flows and key fields.

Negative cases

Goal: Invalid or unauthorized request → expected error status (4xx/5xx) and consistent error body.

Examples:

• POST with missing required field → 400 and validation message.
• GET /users/999 when 999 does not exist → 404.
• Request without auth or with invalid token → 401.
• Request with valid auth but no permission → 403.
• Invalid JSON or wrong content type → 400.

Design negative tests for validation, auth, authorization, and not-found cases.

Edge cases

Goal: Boundaries and special values that might break the API.

Examples:

• Empty string vs null vs omitted for optional fields.
• Min/max length, min/max number (e.g. age 0, 120, 121).
• Empty array or empty body where the API allows it.
• Special characters and encoding in strings.
• Duplicate create (e.g. same email) → 409 or 400.

Combine equivalence partitioning and boundary value analysis (from earlier posts) to pick edge cases.

Summary

• Positive: valid input → 2xx and correct response; cover main flows.
• Negative: invalid/auth/forbidden/not-found → 4xx (or 5xx) and error body.
• Edge: boundaries, empty/null, duplicates, encoding; use boundaries and equivalence classes to choose cases.