Objective & prerequisites
Make rejected inputs and failure messages part of the evidence. Prerequisites: basic Python expressions and files; use a disposable local practice folder and fictional data. This shared workshop complements the existing data/AI tracks and does not create a second progress system.
Understand the concept
A failing test should be investigated rather than weakened until it passes. Distinguish a wrong expected value, defective implementation and changed contract. Capture a minimal reproducible case without private records. Tests that expect rejection are successful when the boundary refuses the invalid operation.
Worked example
The duplicate fixture repeats ID A. It should raiseValueError, so unittest.assertRaises is the expected successful outcome. If the code silently summed both rows, that test would fail even though execution produced a number.
python3 foundation_labs.py FoundationTests.test_contract_rejects_duplicatesTry it yourself
Change the duplicate fixture in a disposable copy to conflicting amounts. Describe why removing duplicates automatically would require a source decision rather than merely a code fix. Record your prediction before running the supplied reference, then compare the observed result and explain any difference.
Worked solution
Both identical and conflicting repeated IDs violate the unique-record contract. The production rule for correction needs evidence. Keep the source, rejection category and affected record identifier in a controlled review log.
Knowledge check
Does a rejection test passing mean the bad input was accepted? Try answering without rereading the example.
Check and explain
No. It means the tested invalid input was refused as intended.
Mini-project, mistakes & handover
Produce a short README with the question, exact local command, input meaning, checks and actual results. Include one failure case and its explanation. Never silently turn an exception into a passing result. Mark simulated behavior explicitly, credit the supplied teaching code and identify your own contribution. These activities are unsaved self-practice, not certification.
Authoritative reference
— consulted for the underlying interface/concept. The lesson and fictional examples are original teaching material. Python reference tested with 3.12; designed for 3.10+. Git lab requires Git 2.28+.
Try the activity before reading its reference. Keep your sources, commands and assumptions with your work. Companion activities are unsaved self-practice and do not award a certificate or change lesson progress.