8. Make tests useful in continuous integration

Objective & prerequisites

Create a repeatable check command and understand what a CI result actually proves. 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

Continuous integration runs defined checks for a change in a controlled environment. It cannot decide whether the underlying business question is sensible. The supplied example workflow checks out a disposable learning repository, selects Python 3.12, compiles the source, runs unittest discovery and executes the valid fixture. It declares read-only repository contents permission and a five-minute timeout. It has no deployment, production credentials, package publication or payment operation. The local check commands are executed for this lesson; the GitHub-hosted workflow itself remains an example until you run it in your own optional practice repository. Action version tags identify chosen releases but are mutable; a real team may pin reviewed full commit hashes and maintain them.

Worked example

The suite has independently known controls: count 4, web 27000, store 13000 and total 40000. A test checks rejected duplicates leave the original ledger unchanged; HTTP tests validate real responses. compileall catches syntax errors but does not prove business correctness. unittest fails with nonzero exit status if an assertion fails, which is how a workflow can stop before subsequent steps. The YAML file sits inside the download kit; it is not enabled in the PHP website repository.

python3 -m compileall -q dch_orders tests
python3 -m unittest discover -s tests -v
python3 -m dch_orders orders.json

Try it yourself

Run the three commands locally. In a disposable copy change the expected total to 40001 and observe a failing assertion; then restore the independent 40000 control. Write a short review explaining why changing the expected answer merely to match a bug would defeat the check. Optionally copy the kit into a new practice GitHub repository to run the example; no account is required to complete the local lesson. 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

Does a green syntax check establish that the reported order total is correct?

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.