Core software skills — DataCareerHub

Nine original companion lessons · DataCareerHub · Fictional data · Payments and public registration disabled.

1. Model reliable records with objects

Objective & prerequisites

Use an immutable value object to enforce a small, explicit data contract. 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 class defines a type; an instance holds the values for one record. A method operates on that instance through self. The supplied Order dataclass groups order_id, channel and amount_cents. Its __post_init__ method checks values after construction. Type annotations help readers and tools but do not perform these runtime checks. frozen=True prevents ordinary reassignment after construction; it is a coding boundary, not a security boundary or proof of deep immutability. Keeping integer cents avoids binary floating-point surprises for this exercise. A valid zero is distinct from a missing value, and bool must be rejected explicitly because Python otherwise treats it as an integer subtype.

Worked example

Order("F01", "web", 12000) represents EUR 120.00 in fictional source data. Creating an order with True, a negative amount, an unknown channel or an empty ID raises ValueError. The upper limit is a declared teaching bound, not a universal financial rule. The frozen object has only immutable string and integer fields. An object with a mutable list field would require additional reasoning even if the dataclass were frozen.

from dch_orders import Order
order = Order("F01", "web", 12000)
assert order.amount_cents == 12000

Try it yourself

Create one valid zero-value order. Predict and then test True, -1 and "12000" as amounts. In a local copy, add an optional currency field with only EUR allowed, and update every constructor and test that depends on the schema. Explain why silently converting a string or boolean would obscure the source contract. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

Zero remains valid; True, -1 and the string are rejected. Check type(value) is int before numerical bounds. A new currency field must be validated and documented at both JSON and object boundaries; otherwise the CLI and service may disagree. Compare your implementation with dch_orders/__init__.py and tests/test_orders.py. Existing tests deliberately use invalid construction to challenge the contract.

Knowledge check

Does writing amount_cents: int prevent callers from passing True?

Check and explain

No. An annotation does not enforce runtime types, and isinstance(True, int) is true. This contract deliberately checks exact integer type.

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

https://docs.python.org/3.12/library/dataclasses.html — 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.

2. Use composition and protect independent state

Objective & prerequisites

Build a ledger around validated records without unnecessary inheritance. 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

Composition means one object uses other objects: Ledger holds an ID-indexed dictionary of Order instances. It does not inherit from dict because an unrestricted dictionary interface could bypass duplicate and type checks. Every Ledger initializes its own dictionary inside __init__. A mutable class attribute would be shared across instances. The leading underscore in _orders is a convention, not access control. The public summary method returns a newly constructed result so a caller changing that result does not change the ledger. Validation should happen before mutation; a rejected duplicate must leave the original record and total intact.

Worked example

Two ledgers start empty. Adding F01 to the first leaves the second empty. Adding F01 again is rejected even if the amount differs. The original total remains 12000 cents. The implementation does not overwrite, deduplicate or merge conflicting records because those actions require a source-resolution rule. In production a larger batch import might need transaction semantics; this teaching function builds a new local ledger and returns it only when every row is valid.

from dch_orders import Ledger, Order
a, b = Ledger(), Ledger()
a.add(Order("A", "web", 100))
assert a.summary()["total_cents"] == 100
assert b.summary()["count"] == 0

Try it yourself

Run test_separate_instances and test_duplicate_preserves_original. Construct two ledgers, change the dictionary returned by summary() and confirm that a later summary is unchanged. Sketch why a shared class-level dictionary would contaminate another analysis. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

Create self._orders = {} for each instance. Check the ID before assigning it. summary builds new totals every call, so modifying a returned summary does not alter Order objects or the internal index. Composition keeps the supported interface small; it does not prevent deliberately accessing a Python underscore attribute. That distinction matters when explaining maintainability versus security.

Knowledge check

Would making Ledger a subclass of dict automatically enforce unique-ID rejection?

Check and explain

No. Ordinary dictionary assignment overwrites an existing key. A focused composed interface makes the intended rejection rule easier to inspect and test.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/tutorial/classes.html — 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.

3. Choose lists, dictionaries, sets and queues

Objective & prerequisites

Choose a data structure that preserves the meaning of your analysis. 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 list preserves sequence and permits duplicates. A dictionary maps unique keys to values; repeated assignment replaces a value unless you check first. A set supports distinct membership but loses repeated occurrences and is not a reliable presentation ordering. A deque supports efficient additions and removals at both ends and is useful for a first-in-first-out work queue. Structure choice is part of the data contract: converting source records to a set cannot resolve two conflicting versions of one business event. A unique-ID dictionary makes lookup convenient, but you must reject or explicitly reconcile duplicates before insertion.

Worked example

The fixture has four source rows: F01 web 12000, F02 store 8000, F03 web 15000, F04 store 5000. A list preserves all four input observations. Ledger indexes four IDs and calculates web 27000, store 13000, total 40000 cents. The invalid fixture repeats F01 with conflicting information. It must fail; allowing the later assignment to win would turn an evidence conflict into an undocumented correction.

from collections import deque
queue = deque(["F01", "F02", "F03", "F04"])
assert queue.popleft() == "F01"
assert len(queue) == 3

Try it yourself

Build a list of the four IDs, a set of channels and a dictionary mapping ID to cents. Check for duplicates before constructing the dictionary. Use collections.deque to process IDs in input order. State what would be lost if you used a set for the queue. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

The ID list is F01,F02,F03,F04; the channel set contains web and store with no display-order guarantee. The ID mapping has four entries. The queue removes F01 first using popleft(). A set would remove duplicate occurrences and would not preserve the intended FIFO sequence. See solutions/worked-solutions.txt for a complete runnable answer.

Knowledge check

Can a four-entry dictionary prove the original file contained exactly four records?

Check and explain

No. Duplicate keys may have been overwritten before you counted. Preserve and validate the source list, then reconcile source count with the unique-key index.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/tutorial/datastructures.html — 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.

4. Explain complexity with counted operations

Objective & prerequisites

Compare algorithm growth without confusing measurements with guarantees. 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

Complexity describes how work or storage grows with input size under stated assumptions. Scanning a growing list to detect every duplicate in an all-unique sequence performs 0+1+...+(n-1) comparisons: n(n-1)/2, which is quadratic growth. A set-based approach makes n membership calls and uses additional storage. Typical hash-table membership has expected constant-time behavior under normal assumptions, but this lesson does not promise a fixed worst-case time. Sorting usually changes the tradeoff to O(n log n), while a streaming running sum can be O(n) work with constant aggregate storage if uniqueness is checked elsewhere.

Worked example

comparison_counts(10) gives 45 list comparisons and 10 set membership calls. At 100 it gives 4950 and 100. A tenfold input increases the counted scan comparisons by 110 times in these two finite fixtures. As n grows, quadratic scaling tends toward a hundredfold work increase for tenfold n. These counts are not seconds, CPU instructions or evidence that the set operation itself has zero cost.

from dch_orders import comparison_counts
assert comparison_counts(20) == {"list_comparisons": 190, "set_membership_calls": 20}
print(comparison_counts(200))

Try it yourself

Predict counts for n=0,1,20,200 and confirm them with comparison_counts. Calculate the list formula by hand for n=20. Explain why timing one tiny run is poor evidence of a general scaling law. Identify the O(n) storage used by the set and seen list. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

For n=0 the counts are 0 and 0; n=1 gives 0 and 1; n=20 gives 190 and 20; n=200 gives 19900 and 200. Both implementations retain an index growing with n. The helper bounds n at 1000 to avoid turning a teaching comparison into an accidental expensive run. The supplied tests assert independent known counts rather than elapsed-time thresholds.

Knowledge check

Does observing 100 membership calls prove the program takes exactly 100 units of time?

Check and explain

No. A call count describes an instrumented operation, not its hardware cost. State the operation, assumptions, memory tradeoff and tested input range.

Evidence & common mistakes

Authoritative reference

5. Organize a package and a reproducible command

Objective & prerequisites

Move from a loose script to a reusable package with a clear command-line boundary. 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 module is an importable Python file. This regular package is the dch_orders directory with __init__.py, __main__.py and service.py. Running python -m dch_orders executes __main__.py; importing dch_orders exposes the model functions without starting a server or running a CLI. This is a source package, not a published distribution or installed wheel. A virtual environment separates project packages from another project, but does not by itself lock dependencies or isolate untrusted code. This kit has no third-party dependencies and does not require pip installation. Working-directory instructions still matter because the interpreter must locate the source package.

Worked example

From software-kit, python -m dch_orders orders.json reads the bounded UTF-8 file, validates it and prints one JSON summary to stdout. A bad source exits 2 with a generic category on stderr and no result on stdout. __main__.py puts command behavior behind main() and the __name__ guard. Missing files and malformed JSON are reported as rejected input. It never overwrites the source or writes an output unless the learner explicitly redirects stdout.

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

Try it yourself

Create a virtual environment in your practice directory, run the CLI with the valid and invalid fixtures, then invoke it from a different directory and explain the result. Capture stderr separately without replacing your source. Do not install the teaching package globally. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

On macOS/Linux use python3 -m venv .venv followed by .venv/bin/python -m dch_orders orders.json. On Windows use py -m venv .venv followed by .venv\Scripts\python.exe -m dch_orders orders.json. Run these inside software-kit. The valid summary totals 40000 cents and returns 0; invalid duplicates return 2. If the source directory is not importable from the new working directory, Python cannot find the package. A future wheel would require explicit distribution metadata/build tooling, which is not supplied or claimed here.

Knowledge check

Does adding an __init__.py file publish or install your package?

Check and explain

No. It makes this source directory a regular package when its parent is importable. Distribution building, installation and publishing are separate operations.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/tutorial/venv.html — 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.

6. Run a real loopback REST service

Objective & prerequisites

Observe HTTP requests and responses against a small local server. 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

An HTTP route combines a method and path with a documented contract. This actual teaching server binds only 127.0.0.1 on an operating-system-selected port. GET /health describes the lab. POST /v1/summary accepts a closed orders JSON envelope and returns a computed summary without saving anything. POST is used to submit a calculation, not to create a persistent resource, so success returns 200 rather than 201. A socket connection and JSON parsing are separate layers. The server has no accounts, authentication, persistence, TLS, public ingress or service-level promise. Python http.server is not suitable for production; do not bind it to 0.0.0.0, upload it to Aruba as an application service, or send private information.

Worked example

Run python -m dch_orders.service in terminal A and copy its printed port. In terminal B, use the client below, replacing YOUR_PORT with that number. Four fictional source rows return count 4 and total_cents 40000. The client sets a five-second timeout and reads the actual HTTP response. This is different from the earlier pure-function mock: tests start an ephemeral server and send real HTTP requests, then shut it down.

import http.client, pathlib, json
# Replace YOUR_PORT with the port printed by the local service.
port = YOUR_PORT
connection = http.client.HTTPConnection("127.0.0.1", port, timeout=5)
try:
    connection.request("POST", "/v1/summary", body=pathlib.Path("orders.json").read_bytes(), headers={"Content-Type": "application/json"})
    response = connection.getresponse()
    print(response.status, json.loads(response.read()))
finally:
    connection.close()

Try it yourself

Start the service, request /health, submit orders.json and stop with Ctrl+C. Record the port, response status, Content-Type and decoded total. Try GET /unknown. Explain why receiving a response does not prove the analytical source is complete. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.

Worked solution

/health returns 200; a valid summary returns 200 with web 27000 and store 13000; /unknown returns 404. No database or remote account is involved. The automated HTTP suite creates its own port so it does not depend on your manually running server. The bounded teaching service is single-threaded; the timeout limits a body read but is not a production resource-exhaustion defense.

Knowledge check

If the local server returns 200, is it now safe to expose publicly?

Check and explain

No. The result verifies a local fixture. Public deployment requires a separate architecture, authentication/authorization where appropriate, supported server, TLS, operating limits and deployment review.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/library/http.server.html — 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.

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.

Worked solution

Use HTTPTests.post with the two payloads. True parses as a boolean, then fails exact integer validation; duplicate object keys fail strict parsing earlier. A caller should repair its request for 400/411/413/415/422, not retry blindly. A timeout can have several causes; this stateless calculation can be repeated with the same input, but that does not establish retry safety for writes such as payments.

Knowledge check

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

Check and explain

No. The transport delivered an application response. Inspect the stable category and contract rather than treating a rejected input as a connectivity failure.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/library/http.client.html — 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.

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.

Worked solution

The valid local commands pass, while the deliberate incorrect expected result fails. Restore the fixture rather than weakening the implementation. Record hosted CI as unexecuted unless you have its actual run evidence. A green local or hosted run does not cover other Python versions, Linux permissions, dependencies or deployments that were not exercised.

Knowledge check

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

Check and explain

No. Syntax checks establish parseability. Independent fixtures and meaningful negative tests establish narrower behavior, and human review checks the question and evidence.

Evidence & common mistakes

Authoritative reference

https://docs.github.com/en/actions/tutorials/build-and-test-code/python — 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.

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.

Worked solution

The worked reference in solutions/worked-solutions.txt shows a five-order ledger totaling 42000, with store 15000 and web unchanged. A repeat of F05 fails. Your README should say this is fictional completed-order input under a declared contract, not revenue recognition or a deployed finance service. Mark hosted CI, Linux-specific permission tests, wheel distribution and production hosting as unexecuted. Deeper Linux commands require a disposable Linux environment in a later verified lab; macOS tests are not Linux evidence.

Knowledge check

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

Check and explain

No. It demonstrates the source, local CLI, data-model and loopback HTTP behaviors actually tested. Additional environment-specific claims require their own evidence.

Evidence & common mistakes

Authoritative reference

https://docs.python.org/3.12/library/unittest.html — 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.