Skip to main content

Module 6 · API testing

Meaningful response assertions

Check what matters: status, structure, values, headers and side effects.

About 9 min reading and 15 min practice (estimates)

Loading progress…

Read

Learning objectives

  • Write assertions that would fail if the feature were wrong.
  • Check side effects, not just the response.
  • Avoid brittle assertions on values that legitimately change.

Explanation

A test that only checks "status is 200" would pass even if the API returned the wrong price or saved nothing. For each request, ask: what would be different if this were broken? Assert that.

  • Status code and content type.
  • Structure: required fields exist with the right types (a JSON Schema helps).
  • Values: calculated fields are correct for your input — totals, discounts, rounding, currency.
  • Headers that matter: Location after creation, caching, rate-limit headers.
  • Side effects: a follow-up GET returns the new state; a webhook or email was sent; nothing else changed.
  • Avoid asserting ids, timestamps or ordering unless they are part of the contract — check their format instead.

Example: assertions for creating an order

Illustrative — not a working endpoint.

POST /v1/orders  { items: [{ id: "coffee-cups", qty: 2 }], code: "SOUQ10" }

Assert
- status 201; Content-Type application/json
- body.id matches /^ord_[a-z0-9]+$/        (format, not a fixed value)
- body.items[0].lineTotal == "16.500"
- body.discount == "1.650"                 (10% of every eligible unit)
- body.total == body.subtotalAfterDiscount + body.delivery
- Location header == /v1/orders/{body.id}
- GET /v1/orders/{body.id} returns the same totals
- the order.created webhook arrives once
Illustrative checklist for a fictional API; field names are examples.

Common mistakes

  • Asserting only the status code.
  • Copying the whole response as the "expected" value, so any harmless change fails the test.
  • Not cleaning up created data, so later tests depend on earlier ones.

Try

Practise what you just read. Answers are checked here; nothing is graded publicly or counts toward Bug Arena.

Exercise

List the assertions you would write for "PATCH /v1/cart/items/coffee-cups { quantity: 3 }" on a cart that had quantity 2. Include at least one side effect.

Write your answer first, then compare it with the sample solution. It stays on this page only and isn't sent anywhere.

Review

Check yourself — you should now be able to:

  • Write assertions that would fail if the feature were wrong.
  • Check side effects, not just the response.
  • Avoid brittle assertions on values that legitimately change.

Practise in QA Lab

References

Continue

When you’re ready, mark the lesson complete in the Try step and move on.

Marked as read when you reach the end of the lesson.