7. Test HTTP failures and preserve the contract

Objective & prerequisites

Use status codes and negative tests to distinguish malformed data from invalid records. Before starting: basic Python functions, dictionaries, loops, JSON and terminal use. Complete the earlier Git/API/testing workshops if these are unfamiliar. Download and extract the kit into a new practice folder, then open a terminal in the software-kit folder. Python 3.10+ is required; the reference uses only the standard library. Work with the supplied fictional data. These free companion lessons do not change protected course access or award progress or certificates.

python3 --version
python3 -m unittest discover -s tests -v

Understand the concept

Failure behavior is part of an API contract. This lab rejects a missing Content-Length with 411, invalid length or unsupported transfer encoding with 400, more than 16384 body bytes with 413, unsupported media type with 415, malformed UTF-8/JSON with 400 and valid JSON that violates the order schema with 422. JSON objects with repeated keys are ambiguous, so strict_json rejects them rather than accepting the last value. Unexpected fields, boolean money, duplicate business IDs and more than 100 rows are contract errors. The server refuses browser Origin headers and sends no CORS permission; this is a teaching restriction, not authentication. Never describe it as protection for a private production API.

Worked example

A payload containing orders:[{}] is syntactically valid JSON but lacks required record fields, so the response is 422. A single opening brace is malformed JSON and returns 400. Sending text/plain returns 415 before record processing. The error response contains a stable generic category without echoing source records. The connection uses HTTP/1.0 and is closed after the response, avoiding reuse after a rejected body. Tests check both successful calculation and independent boundary failures.

python3 -m unittest discover -s tests -p test_http.py -v

Try it yourself

Run test_http.py through unittest discovery. Add a new test sending True as amount_cents and expect 422. Add a duplicated JSON key and expect 400. Write a decision table that maps observation, status and caller action. Do not automatically retry malformed or invalid inputs. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Knowledge check

Is every JSON response with a 4xx status caused by a network outage?

Evidence & common mistakes

Record the exact command, Python version, observed output and one rejected input. Explain what each check establishes and what it leaves untested. Do not remove validation merely to obtain a passing result. A local passing suite is evidence for these fixtures, not proof of production readiness. Credit the teaching reference and distinguish your own changes. The kit includes an exercise worksheet, a separate worked-solutions document, an API contract, expected results and a capstone rubric.

Authoritative reference

Read the official reference ↗

— official reference for the underlying interface. Lesson prose and fictional order examples are original. The teaching HTTP service is loopback-only, stateless and not suitable for production or uploading as a running Aruba service. No cloud account, paid API or registration is required.