THE FREE ENGINEERING LAB

Good engineering
starts with evidence.

Make a request. Find the bug. Prove the fix.
Learn the testing habits that make software more dependable.

No payment required Work at your own pace About 40 minutes

API FOUNDATIONS

…/ 03 lessons

Your next useful skill starts here.

LESSON 02 / 03 · 12 MIN

Find what happens at the edges

Reproduce a regression, then prove the expected behavior.

The next version of the API is ready for review. The usual order works, but a small change to a comparison operator can quietly move a boundary. You need evidence before you approve the release.

For an allowed interval of 1 through 10, a compact boundary suite checks 0, 1, 10, and 11. These values sit immediately outside and directly on the boundaries. Our candidate build deliberately contains training bugs: it accepts zero items and rejects ten. The reference build follows the contract. Both builds run locally and deterministically; no real checkout is involved.

Read the API contract POST /sandbox/quote

Teaching simulator: requests run entirely in your browser. They do not contact a server, create orders, or take payments.

quantity: Required integer, 1–10 inclusive. Missing, fractional, or below 1: 400 INVALID_QUANTITY. Above 10: 400 QUANTITY_LIMIT.
coupon: Optional. Omit or leave empty for no discount. LEARN10 gives 10% off and ignores letter case. Any other value: 400 INVALID_COUPON.
Success: 200 with currency, quantity, unitPrice, subtotal, discount, and total. Money uses USD cents. Unit price is 2500; total = subtotal − discount.
Validation order: Quantity type and minimum, then maximum, then coupon. Additional request fields are ignored.
Builds: Reference follows this contract. Candidate intentionally accepts 0, rejects 10, and checks coupon letters case sensitively.

YOUR CHALLENGE

Run the four contract-based checks on the candidate. Inspect the two failures, then switch to the reference build and run the same suite again.

Keep the expected outcomes based on the contract: 0 and 11 must fail; 1 and 10 must succeed.
Run the candidate build. Expand the failed results and identify each incorrect status or total.
Switch to the reference build without changing those expected outcomes.
Run again. Completion requires both the reproduced candidate failures and a passing reference suite.

Your workbench

LOCAL SIMULATOR

Select a buildContains deliberate bugs for you to investigate.

01 Explore a requestTry an input. Inspect the response.

POST /sandbox/quote

quantity JSON value · empty means missingcoupon optional

RESPONSE

// Send a request to inspect
// its actual response here.

// Nothing leaves your browser.

Write your assertions

JSON data. Match the status and the body fields that matter.

JSON assertion suite for Find what happens at the edges

1–12 cases · status is required · body fields are partial matches

03 / REVIEW THE EVIDENCE

What did your tests prove?

Run your suite to see the result of every assertion.

The checklist below measures coverage as well as correctness.

Required evidence

Reproduce both the zero and ten regressions on the candidate build

Check quantity 0 returns status 400 and INVALID_QUANTITY

Check quantity 1 returns status 200 and total 2500

Check quantity 10 returns status 200 and total 25000

Check quantity 11 returns status 400 and QUANTITY_LIMIT

Run a reference suite with every assertion passing

TAKE THIS WITH YOU

A useful regression test fails on the broken version and passes on the corrected version. A green test that never exposed the bug is weaker evidence.

Complete the evidence checklist to finish this lesson.

Loading Engineer Africa…

Good engineeringstarts with evidence.

Find what happens at the edges

Your workbench

Write your assertions

What did your tests prove?

Required evidence

Good engineeringstarts with evidence.

Find what happens at the edges

Your workbench

Write your assertions

What did your tests prove?

Required evidence

Good engineering
starts with evidence.

Good engineering
starts with evidence.