9. Deliver a reviewable software mini-project

Objective & prerequisites

Hand over a tested fictional order-summary tool with honest operating limits. 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

A useful handover joins domain meaning, implementation, validation and operation. Your deliverables are the source, a source-data dictionary, CLI/API contract, test results, failure decision table and README. A review should trace each reported number back to a declared fixture and identify what was rejected. The capstone changes the learning code, not the DataCareerHub application. Preserve the original kit and work on a copy. No confidential records, public endpoint, paid account or certificate is required. A local practice artifact can support a portfolio only when you describe the teaching starting point and your own contribution truthfully.

Worked example

Baseline controls are four orders and EUR 400.00. Your extension adds a separately validated fifth order, F05 store 2000 cents. The new expected values are count 5, web 27000, store 15000 and total 42000. Add a test for that exact extension and another proving that a repeated F05 is rejected. The original fixture and expected.json remain unchanged so that the baseline suite still verifies compatibility. Tests for your new fixture provide separate evidence.

from dch_orders import from_payload, strict_json, Order
from pathlib import Path
ledger = from_payload(strict_json(Path("orders.json").read_text()))
ledger.add(Order("F05", "store", 2000))
assert ledger.summary() == {"count": 5, "total_cents": 42000, "by_channel": {"web": 27000, "store": 15000}}

Try it yourself

Complete exercises/worksheet.txt and add your own fifth-order fixture. Extend tests without changing the baseline expectations. Run CLI and HTTP checks, document one failed input and include your actual environment. Use capstone-rubric.txt for a self-review. Provide a short explanation for a non-technical reviewer that states currency, source population, rejection policy and scope. 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

Can you claim that the kit proves your cloud deployment or Linux operations skills?

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.