Tests and quality checks

Choose a check for a specific kind of mistake

A build transforms source into an artifact. A test compares behavior with an expectation. A linter looks for configured code patterns; a formatter checks layout. These activities overlap in usefulness but do not establish the same result. A successful image build can still contain a broken calculation or an API that cannot reach its database.

Start with the Python capacity tool whose inputs and expected results you already know. Its pure function test checks arithmetic and rejected inputs; its file test checks reading and validation. A CLI test adds arguments, stdout/stderr, and exit status. The loopback HTTP exercise covers a different integration. A full application transaction exercises several components together and needs a deliberately prepared environment.

Prove the gate notices a defect

From the capacity project's root, run:

python -m unittest discover -s tests -v

Read the discovered count and test names. If you retained test_status.py as well as test_capacity.py, the count differs from the five capacity tests alone. To select only those five, add -p 'test_capacity.py'. A green command with zero discovered tests has not checked your intended behavior.

Temporarily change the expected remaining_gib(20, 8) result from 12 to 13. Run the same command and inspect the assertion failure and nonzero exit status. Restore 12 and repeat. This controlled failure proves the command executes that assertion; it does not prove every possible defect is covered.

Build a small check map

Coverage reports tell you which code was executed, not whether assertions were meaningful. A security scan reports findings under its data and rules; it cannot certify that the whole system is secure. Quality gates need a defined failure condition and someone who understands what a pass means.

Inspect MicroBank rather than inventing commands

At the pinned revision, the frontend declares lint and build commands but no test script. Do not label a nonexistent npm test run as passed. Ledger's Dockerfile builds with -DskipTests; an image build therefore does not establish Java test results. Inspect actual test directories, dependency manifests, and runtimes before proposing each service's CI command.

Write a table of service, real command, prerequisites, expected report, and uncovered behavior. Missing tests are implementation work. Keep fast isolated checks on routine changes, and operate local integration and synthetic-user profiles separately. This project's periodic synthetic runs stay local, not on paid cloud targets.

Make failure stop the relevant next step

A required test must propagate its exit code. || true, unconditional success wrappers, or continue-on-error can conceal the defect from a dependent publish job. Use job dependencies and required checks deliberately. If a test is advisory, label it as such instead of presenting it as a release gate.

Checkpoint: a scan passes and the unit suite passes; can the API still fail after deployment? Yes—configuration, target identity, dependencies, and runtime behavior remain. Next, pass the actual build output through CI without confusing a dependency cache with a trusted release.

References: Python testing in Actions↗, MicroBank frontend commands↗, and Ledger Dockerfile↗.