How do I validate error responses and edge cases in API testing?

To validate error responses and edge cases in API testing, focus on whether the API handles invalid inputs, unexpected conditions, and boundary values consistently and safely.

1) Test common error scenarios

Check how the API responds when requests are malformed or invalid:

• Missing required fields
• Invalid data types
• Invalid formats
  • bad email
  • malformed date
  • wrong UUID
• Out-of-range values
• Empty payloads
• Unauthorized / forbidden access
• Non-existent resources
• Duplicate requests or duplicate IDs
• Unsupported HTTP methods
• Invalid content type (Content-Type: text/plain instead of application/json)

2) Verify HTTP status codes

Make sure the API returns the correct status code for the situation:

• 400 Bad Request → invalid input
• 401 Unauthorized → missing/invalid authentication
• 403 Forbidden → authenticated but not allowed
• 404 Not Found → resource doesn’t exist
• 409 Conflict → duplicate or conflicting data
• 422 Unprocessable Entity → validation failure in some APIs
• 429 Too Many Requests → rate limiting
• 500 Internal Server Error → unexpected server issue

3) Validate the error response body

Error responses should be useful and consistent. Check for:

• A clear error code
• Human-readable message
• Field-level validation details
• Timestamp or trace ID if applicable
• Consistent structure across endpoints

Example:

{
  "error": "VALIDATION_ERROR",
  "message": "Email is invalid",
  "details": [
    {
      "field": "email",
      "issue": "must be a valid email address"
    }
  ]
}

4) Check boundary and edge cases

Test values at and around limits:

• Minimum and maximum allowed values
• Just below and just above limits
• Very large payloads
• Long strings
• Special characters
• Unicode / emoji
• Null vs empty string vs missing field
• Timezone and date boundary cases
• Pagination edge cases (page=0, negative values, huge page numbers)

Examples:

• age = 0, age = -1, age = 150
• name = "", name = null, name = "a"*1000
• pageSize = 1, pageSize = 1000

5) Test request and protocol-level edge cases

Also validate behavior when requests are technically unusual:

• Invalid JSON syntax
• Wrong headers
• Missing auth token
• Expired token
• Unsupported media type
• Corrupted payload
• Repeated submissions
• Slow or timeout scenarios

6) Ensure security-related error handling

Error responses should not leak sensitive info:

• No stack traces in production
• No database details
• No internal file paths
• No secret values or tokens
• Generic messages for server failures

7) Automate assertions

In your tests, assert:

• Status code
• Response schema
• Error message/content
• Presence/absence of sensitive information
• Consistency across endpoints

Example assertions:

• status == 400
• error == "VALIDATION_ERROR"
• details[0].field == "email"

8) Use negative testing systematically

Create test cases for invalid inputs on each endpoint:

• Required fields omitted
• Wrong types and formats
• Invalid IDs
• Boundary values
• Invalid auth
• Rate limit triggering
• Duplicate resource creation

9) Consider contract testing

If your API has a defined schema, validate that error responses also follow a contract:

• schema shape
• required fields
• allowed error codes
• response format consistency

10) Example test cases

Scenario	Input	Expected
Missing required field	{"name":"John"}	400, validation error
Invalid email	{"email":"abc"}	400, field error
Non-existent ID	/users/99999	404
Unauthorized request	no token	401
Duplicate create	same email twice	409
Too large value	age=1000	400 or 422

Good practices

• Keep error responses consistent
• Validate both status code and payload
• Cover boundary values, not just random invalid data
• Don’t assume one error path covers all cases
• Automate regression tests for known failures

If you want, I can also give you:

1. a negative test checklist,
2. a Postman example, or
3. a pytest / RestAssured sample for error-response validation.