Boundary Cases for API Inputs (Lab)
A hands-on lab: apply boundary-value analysis specifically to API payloads — numeric limits, string lengths, array sizes, and pagination edges.
What you'll learn
- Identify boundary values for a documented numeric or length limit in an API
- Design test cases for empty, minimum, and maximum-sized collections
- Explain pagination edge cases specific to API testing
Prerequisites
Explanation
Boundary-value analysis (from Software Testing Foundations) applies directly to API payloads, with a few API-specific shapes worth calling out explicitly. A documented limit like "a product name must be 1 to 100 characters" produces the familiar six boundary values (0, 1, 2, 99, 100, 101 characters) — nothing new there. What's specific to APIs is testing the edges of collections and pagination, which have no equivalent in a single-field form.
An empty collection (a user with zero orders) is a boundary case its own right — does GET /users/7/orders return an empty array [], or does it error, or return null? All three are plausible implementations and only one is usually correct per the API's contract; a test suite that only ever tests users with orders will never notice this.
A collection at the documented maximum size (if an API states "returns up to 100 items per page") needs a request that returns exactly 100, one that returns 101 (does it truncate, error, or silently return everyone?), and a request for page 2 to confirm pagination actually advances rather than repeating page 1.
Pagination-specific edges deserve their own checklist: requesting a page number of 0 or negative (should this be rejected or clamped to page 1?); requesting a page far beyond the last page of real data (should this return an empty array, or error?); requesting a page size of 0 (division-by-zero-shaped bugs love this exact input). None of these are exotic hacker inputs — they're the kind of value a legitimate client can produce accidentally from a bug in its own pagination logic, which makes handling them gracefully, not just theoretically, a real production concern.
Example
A simulated paginated response, with a boundary check for a page number beyond the available data.
function paginate(items, page, pageSize) {
if (page < 1 || pageSize < 1) return { status: 400, error: "invalid pagination parameters" };
const start = (page - 1) * pageSize;
const pageItems = items.slice(start, start + pageSize);
return { status: 200, body: pageItems, totalItems: items.length };
}
const items = ["a", "b", "c"]; // simulated dataset -- not a real API call
console.log(paginate(items, 1, 2)); // page 1: ["a", "b"]
console.log(paginate(items, 5, 2)); // page 5: past the end -- what should this return?Try it yourself
Try page 0 and a negative pageSize below and predict what should happen before running.
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
A product name field allows 1 to 50 characters. List the six boundary-value lengths as an array in ascending order named boundaryLengths.
Checks: returns the correct six boundary lengths in order
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
Write a function paginationEdgeCase(page, pageSize, totalItems) that returns 'invalid' if page < 1 or pageSize < 1, 'empty-page' if the page is beyond the last page of real data, or 'normal' otherwise.
Checks: page 0 is invalid · an in-range page is normal · a far-beyond-range page is empty-page · a negative pageSize is invalid
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Only testing pagination with realistic, in-range page numbers and never testing page 0, negative pages, or pages far beyond the data.
- Assuming an empty collection will be handled the same way as a populated one without actually testing the empty case.
- Not testing the exact boundary of a documented maximum page size (e.g. exactly 100 vs. 101 items requested).
Knowledge check
Takeaway
Boundary-value analysis for APIs extends beyond single-field limits to collection edges — empty results, maximum page sizes, and pagination parameters a legitimate client can accidentally send.
Summary
This lab practiced applying boundary-value analysis to API-specific shapes: field length limits, empty collections, maximum page sizes, and pagination edge cases like page 0 or a far-out-of-range page.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.