BVA and Equivalence Partitioning for API Testing: Request Parameters, Headers, and Payloads

API testing benefits from the same systematic input analysis as any other testing, but the input space is more structured: path parameters, query parameters, headers, and request bodies — each with their own validation rules and boundary conditions.

This post applies BVA and equivalence partitioning specifically to REST API inputs.

The API Input Taxonomy

Before partitioning, classify API inputs:

Path parameters (required, typed):

GET /users/{userId}
GET /orders/{orderId}/items/{itemId}

Query parameters (optional, typed, may have ranges):

GET /products?page=1&limit=20&min_price=10&max_price=100

Request headers (typed, often with restricted value sets):

Authorization: Bearer <token>
Content-Type: application/json
Accept-Language: en-US

Request body (structured, may have nested objects with their own validation):

{
  "name": "John Doe",
  "age": 25,
  "preferences": ["email", "sms"]
}

File uploads (size, type, content constraints)

Each category has different partition structures.

Path Parameters

Path parameters are typically IDs or resource identifiers. Common partition structure:

Numeric ID partitions

For GET /users/{userId}:

The overflow value (max int64 + 1) tests whether the API handles large numeric strings without crashing. Many APIs crash or produce wrong results when a numeric ID exceeds the integer type used internally.

UUID partitions

For GET /resources/{uuid}:

The nil UUID partition is interesting: some systems treat it specially, some don't. Testing it reveals the system's behavior for this edge case.

Query Parameters

Query parameters are often optional, which adds a "missing" partition in addition to the usual value partitions.

Pagination partitions

For GET /products?page={page}&limit={limit}:

Page parameter (typically 1-indexed, must be positive):

Limit parameter (typically 1–100):

The interaction between page and limit matters: page=100, limit=100 with a 50-item dataset should return empty results, not an error. Testing "page beyond last" requires knowing the total count — use a small dataset in tests to control this.

Filter parameter partitions

For GET /orders?status={status}&from_date={date}&to_date={date}:

Status filter (enum: PENDING, CONFIRMED, SHIPPED, DELIVERED, CANCELLED):

Date range (from_date / to_date):

The inverted range partition (from > to) is commonly missed. Many APIs silently return empty results instead of an error.

Request Headers

Headers have value-type partitions and also have the "missing required header" partition.

Authorization header partitions

For Bearer token authentication:

The "wrong permissions" partition distinguishes 401 (unauthenticated) from 403 (authenticated but unauthorized). Many APIs return 403 for everything or 401 for everything — testing this partition verifies correct HTTP semantics.

Content-Type header partitions

For POST/PUT endpoints:

Request Body Partitions

Complex request bodies need partitioning at multiple levels.

Structural partitions (JSON body)

For any JSON request body:

Field-level partitions

For each field in the request body, apply the relevant EP rules based on type (string, numeric, date, enum, collection — as covered in the previous sections).

Additionally for required/optional:

Testing every combination of missing required fields is O(2^n) — impractical. At minimum, test: each required field missing independently, and all required fields present.

Nested object partitions

For nested objects, apply partitions recursively:

{
    "user": {           // Required object
        "name": "...",  // Required field
        "email": "...", // Required field
        "address": {    // Optional nested object
            "street": "...", // Required if address present
            "city": "..."    // Required if address present
        }
    }
}

Partitions for the address object:

• Address absent (valid — optional)
• Address present, fully specified (valid)
• Address present, street missing (invalid — required if address present)
• Address present as empty object {} (invalid — required fields missing)
• Address present as null (treat as absent, or error?)

Rate Limiting Boundaries

APIs with rate limiting have boundary conditions at the rate limit itself:

Rate limiting tests require time control — you need to know when the rate limit window starts and resets. Testing this against a real API requires either a mock rate limiter or timing the requests to a specific window.

Check that 429 responses include:

• Retry-After header
• X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers
• Clear error message

Idempotency Partitions

For idempotent operations (PUT, DELETE), test:

Idempotency bugs are common in distributed systems: a network timeout causes a retry, and the system incorrectly processes the same operation twice.

Documenting API Partitions

For each API endpoint, document the partition structure in a test plan:

Endpoint: POST /orders
Parameter: body.quantity (int)

Partitions:
- EP1 (invalid): quantity < 1 → 400 (test with: 0, -1)
- EP2 (valid): 1 ≤ quantity ≤ 100 → 201 (test with: 1, 50, 100)
- EP3 (invalid): quantity > 100 → 400 (test with: 101, 1000)
- EP4 (invalid): non-integer → 400 (test with: "five", 1.5)
- EP5 (invalid): missing → 400 (test with: field absent)

This documentation makes partition coverage explicit and reviewable. It's also the specification for automated test generation.

Summary

BVA and EP for APIs follow the same principles as any input analysis: identify the behavioral regions, test one representative from each region, test the boundaries between regions.

The API-specific additions: path parameters need overflow and injection partitions; query parameters need "missing" partitions; headers need "wrong scheme" and "wrong permissions" partitions; request bodies need structural partitions in addition to field-level partitions.

The combination of systematic EP with BVA at the boundaries produces test suites that cover the full input space at reasonable cost — a fraction of the tests that exhaustive testing would require, while covering the failure modes that matter.