Validation Suite for a Sample Learning-Progress API

1. Document the API and write a schema validator

The target: a simulated learning-progress API with one resource, an 'enrollment' — { id: number, courseSlug: string, status: "active" | "completed", progressPercent: number }. Write a schema-validation function checking all four fields' presence and type, and a fifth check that progressPercent is between 0 and 100.

• The schema validator checks all four required fields for presence and correct type
• The validator separately reports a progressPercent outside the 0-100 range as its own distinct error, not lumped in with a type error
• The validator is tested against at least one fully valid fixture and at least two broken fixtures (one missing a field, one with an out-of-range value)

2. Positive and negative tests for creating an enrollment

Design a simulated createEnrollment(payload) function's test cases: one positive case with fully valid input, and at least four negative cases (missing courseSlug, wrong type for progressPercent, an invalid status value not in the allowed set, and progressPercent above 100).

• One positive test case exists and expects success
• At least four distinct negative test cases exist, each targeting a different validation rule
• Every negative test case explicitly asserts that a success response was NOT returned — per this course's key lesson, that would indicate a real defect, not a passing test

3. Apply boundary-value analysis to progressPercent

progressPercent must be between 0 and 100 inclusive. Design and test the six standard boundary values: -1, 0, 1, 99, 100, 101.

• All six boundary values are tested with documented expected results
• The two in-range boundary values (0 and 100) are confirmed to be accepted, not rejected off-by-one
• The test suite clearly documents which values are the boundaries being tested and why, not just a numbered list

4. Test a chained workflow

Chain three steps: create an enrollment (extract its id from the response), update its progressPercent using that extracted id, then fetch the enrollment again and confirm the update is reflected. Include a test for what happens if the update step uses an id that was never actually created.

• The id used in steps 2 and 3 is extracted from step 1's response, never hardcoded
• The final fetch confirms the updated progressPercent value is actually reflected, not just that the update call itself returned success
• A test using a nonexistent enrollment id in the update step expects a 404, not a silent success or a crash

5. Isolate the suite and write a summary report

Restructure the tests so each one creates its own enrollment during setup and does not depend on another test's leftover data. Write a summarizeRun-style function producing a short, actionable report string for the whole suite.

• Every test creates whatever enrollment data it needs itself, rather than assuming another test already created it
• Running any single test alone (in isolation) still passes or fails correctly on its own
• The summary report names the specific failing test(s) when there are failures, not just an aggregate pass/fail count