M06-L04 — Diagnose a fault with one useful test
Distinguish a malformed fixture from a policy fault using one controlled change. Start with CP06. Write the symptom before asking an assistant to name a cause: exact checkpoint, command, expected behavior, actual output/exit, and the smallest relevant input.
Run the supplied failure:
.\scripts\replay.cmd fixtures/invalid.csv
$invalidExit = $LASTEXITCODE
The expected result is exit two with a line-three invalid-sample-number diagnostic. The file contains 28C, which the fixture grammar does not accept. Startup and an earlier valid record may appear before rejection. Preserve stdout and stderr rather than treating partial output as success.
Locate the failure layer. A compiler failure prevents a build; a runtime dependency failure can prevent startup; a parse failure occurs in a running adapter; a policy failure can produce valid JSON with the wrong meaning. Here the line-number diagnostic shows that execution reached fixture parsing. No physical sensor was read.
Name competing explanations: the token violates the format, the parser rejects a supported number, or policy fails after receiving a valid reading. Inspect the format contract and relevant host/replay.cpp code. The adapter requires the complete numeric token; unit suffixes are not part of this small fixture language.
Choose one discriminating test. Copy invalid.csv to lab14-valid.csv and change only 28C to 28. Run the copied fixture through the same source/executable path. Successful acceptance supports the malformed-input explanation while holding policy and toolchain constant.
Copy-Item .\fixtures\invalid.csv .\fixtures\lab14-valid.csv
# Edit only 28C to 28 in the copied file, then save it.
.\scripts\replay.cmd fixtures/lab14-valid.csv
$correctedExit = $LASTEXITCODE
Run the original invalid fixture again. It should still be rejected. The paired result is stronger than a lone pass because it shows that the correction did not weaken the parser. Do not ignore arbitrary suffixes or substitute zero to hide malformed input; both change the meaning of the exercise.
Ask the assistant to explain predicted observations before editing. A useful request supplies the symptom, file, format requirement, and relevant code, then asks for a test that separates explanations. After execution, ask what the result supports and what remains untested. Preserve a contradicted hypothesis rather than rewriting the investigation into an invented straight-line success.
The same approach applies to a stale-policy defect, but the observations differ. At 4001 in stale-recovery.csv, current data must expire. A formatter-only patch can hide the state label while leaving availability or recovery incorrect. Chapter 14's second exercise traces the policy transition; the module challenge first asks you to defend a small fixture correction independently.
Resources and completion
Use CP06, Chapter 14, fixtures/invalid.csv, and the host adapter. Figure references: SS14-01–04. Complete the exercise and consult the key (supplied separately) after recording your own result. A hypothesis is not a root cause until the evidence supports its mechanism.
Recording transcript
When something fails, start with a reproducible observation rather than a diagnosis. In this lesson, the program rejects a synthetic input file. We will locate the failure layer, propose competing explanations, and make one small change that distinguishes them. Open checkpoint six in a new folder and preserve its original files. The physical sensor is not part of this exercise.
Write the command and expected behavior before running it. We are using the replay wrapper with the invalid fixture. Save the actual process exit immediately afterward, and preserve both ordinary output and the error diagnostic. A useful symptom record names the checkpoint, input file, exact command, expectation, and observed result. Another engineer should be able to repeat it without guessing which version you used.
The supplied fixture contains a token with a letter suffix: twenty-eight C. The adapter expects a number without that suffix. The intended failing run exits two and identifies the third file line as an invalid sample number. A startup record and an earlier valid sample may appear first. Partial output does not mean that the rejected token became a valid temperature or that the complete scenario succeeded.
Locate the failure layer before asking for a patch. A compiler failure prevents a successful build. A linker problem prevents the required pieces from combining. A missing runtime dependency can prevent an executable from starting. Here, a line-number diagnostic appears from the running adapter, which tells us execution reached input parsing. That is evidence about where to inspect next, not a physical sensor observation.
Write at least two explanations. Perhaps the fixture violates the supported format. Perhaps the parser wrongly rejects an allowed numeric token. A third possibility is that policy fails after receiving a valid sample. These explanations are not equally supported once we read the diagnostic and code, but stating them helps us choose an experiment instead of jumping directly to a broad rewrite.
Open the format description and the relevant host adapter source. The small fixture language gives temperature a documented unit and requires the complete numeric token to be accepted. It does not support arbitrary unit suffixes on each value. Explicit missing and nonfinite tokens represent modeled input failures. Those valid event descriptions are different from a malformed row that the adapter cannot interpret.
Ask the assistant for a discriminating test before permitting an edit. Supply the exact symptom, small fixture, format requirement, and relevant code. Request a predicted observation for each explanation. A suggestion such as try another input is incomplete unless it names the input change, the command, and how the outcome would affect the diagnosis. The explanation should lead to an executable check.
Choose the smallest useful change: make a copied fixture and remove only the C suffix from the numeric token. Keep the original invalid file. Run the copied file through the same source and executable path. This holds the toolchain, adapter, and policy constant while changing the suspected malformed input. Successful acceptance supports the input-format explanation without inventing a new parser contract.
Do not weaken the parser to ignore every suffix. That could make this one line pass while accepting malformed input that should remain rejected. It would also change the question being tested. You would no longer be checking whether the original token satisfied the existing language; you would be designing a different language. Such a change needs a separate requirement and its own acceptance cases.
Do not replace the failed token with zero simply to remove the error. Zero is a numeric reading with its own meaning. It is not a neutral substitute for an unknown value. If a scenario intends missing input, use the documented missing representation. If it intends a particular temperature, supply that temperature correctly. A plausible invented reading can hide the very failure the program is meant to expose.
After the corrected copy runs, execute the original invalid fixture again. It should still be rejected. This paired result matters: the intended numeric event is accepted while malformed syntax remains outside the contract. Save both observations. A lone passing screenshot would not tell a reviewer whether the parser had been weakened or whether the original reproducer was ever exercised.
Now update the diagnosis using the evidence. The supported cause is a token outside the documented fixture grammar. The correction changes that token, and the unchanged original still reproduces rejection. This conclusion is narrower and more useful than saying the sensor problem is fixed. No sensor was read, no wiring was inspected, and no calibration or physical timing was measured in this run.
If the corrected file still fails, preserve that contradiction. Check whether the command used the copied filename, whether the working directory is correct, and whether the intended executable was rebuilt. Do not repeat the same edit elsewhere and call it a new experiment. The test may reveal that your first explanation was incomplete, which is valuable information when it is recorded accurately.
The chapter also includes a stale-policy fault. That failure occurs after valid input has reached the policy, and it can produce perfectly valid JSON with the wrong meaning. Its useful observations include timestamp, state, error, and temperature availability. Changing only the printed label could hide the symptom while leaving recovery state incorrect. The same investigation method applies, but the discriminating test must match that different failure layer.
Write a concise report from the raw evidence. Include the starting state, original reproducer, competing explanations, chosen test, actual result, bounded correction, regression observation, and limits. An assistant can organize these pieces, but review each sentence against the receipts. Replace unsupported claims of proof with the precise behavior you observed, and keep an unexecuted test labeled as a proposal.
Your exercise is complete when another reader can reproduce the failure, understand why the chosen test distinguishes its cause, and assess the correction without recovering your conversation. Preserve the original invalid input and the corrected copy. In the module challenge, you will apply this method independently to another seeded fixture failure and defend a small fix with a complete evidence handoff.
Download transcript
