LEARN. PRACTICE. GROW.Specify behavior
The exercise uses an invented rule: calculate two percent of a finite nonnegative decimal amount and return cents using HALF_UP for ties. This rule creates an observable defect and does not describe a real banking product. Before programming the test, record approved contract examples, including inputs and expected outputs. For 100.00 the result is 2.00. For 101.25 the exact product is 2.025 and the agreed result is 2.03. Decimal is constructed from text in this script. This avoids introducing an unnecessary binary conversion into the example, but precision, bounds and suitable rules still need consideration when designing a real application.
The case distinguishing implementations
B uses HALF_EVEN where the fictional contract requires HALF_UP. On ordinary input 100.00, both rules produce 2.00; smoke passes on the actually loaded candidate. Input 101.25 forces a tie and distinguishes implementations: B returns 2.02 while A and C return 2.03. The issue is not merely formatting because value changes by one cent. A useful test selects inputs distinguishing permitted behavior from plausible deviations. Finding this defect does not require multiplying identical cases; it requires understanding the requirement and boundary. Other products and operations may require different rules, which should be confirmed with the owners of their contract.
Coverage and outcome
Compare candidate-B-smoke with candidate-B-full. In the first, origin matches and one test passes, but the gate reports missing required results. In the second, four tests execute and the boundary assertion fails. These are different problems: missing coverage and an observed functional deviation. The other two cases require ValueError for -1 and NaN under the fictional rule. These negative tests pass when expected rejection occurs; they do not hide arbitrary errors. The set remains small and covers neither every input nor volumes or integrations. When presenting results, include which cases executed, which passed and what remains outside scope. An aggregate count does not replace that interpretation.
Fix without fitting the test to the defect
In a fictional scenario, the window approaches and the supplier proposes accepting 2.02 to keep everything green. If the contract still requires HALF_UP, changing expected output removes the control that found the problem. Correct the implementation to C and rerun relevant cases, confirming loaded origin. The script observes four passes on C, including the boundary and both rejections. Retain B history: it explains the cause and supports fix review. If the business legitimately wants to change the rule, treat that as a requirement change with impact and reviewed examples. The function under test should not be the sole source of its own expected value.
Acceptance proportional to evidence
The local gate combines matching origin and bytes with four passed IDs. This supports concluding that observed candidate C met those cases in the recorded runtime. It does not prove a real service ready for every load or dependency. The lab installs no wheels, executes no external pipeline and tests no enterprise service. For representative acceptance, plan required environments, configurations, dependencies, integrations and operational observations with their owners. Retain controls over who produces and delivers evidence. A hash read from an owned file is useful for this diagnosis but does not replace execution protection, authenticated origin or supply-chain validation. Preserve those outstanding tasks in the handover rather than inferring they have passed.
Acceptance workshop and summary
Propose a workshop involving business, QA and RUN. Business supplies the fictional rule; QA selects an ordinary case, a boundary and two rejected inputs; development explains the B-to-C change. RUN receives reports and writes a recommendation identifying the target, accepted scope and still-required target checks. The facilitator then introduces a proposal to use the function itself to calculate expected output. The team should explain why that comparison can repeat the defect on both sides. The human workshop was not executed. The automated lab passed ten groups twice. Summarize the sequence: contract, discriminating examples, confirmed target, outcomes, correction and acceptance with explicit limits.
python3 content/labs/cicd-target/run.py --output /tmp/dr-cicd-target-second.json
# Fictional rule: fee=2%, finite nonnegative decimal input, HALF_UP to cents.
# candidate-B-smoke: 100.00 -> 2.00, one passing test, required results missing.
# candidate-B-full: 101.25 -> 2.02, test_boundary fails (expected 2.03).
# corrected-C-full: four required tests pass, origin matches, gate accepts.
# Negative inputs -1 and NaN must raise ValueError under this fictional contract.
# No actual payment, external service, business policy or production approval.Candidate B passes 100.00 → 2.00 but returns 2.02 for 101.25 when the fictional requirement demands 2.03. C corrects the rounding mode.
Common pitfalls
Using only ordinary inputs, changing expectation to follow a defect, adopting a nonexistent universal financial rule or declaring global readiness from four local tests.
Related topics: Artifact identity · Test evidence · Release management
Identifying the target is necessary, but acceptance also depends on relevant cases and expectations independent of the code under evaluation.
Reference: decimal: Decimal arithmetic · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation