Repository navigation
Characterize usage reporting's settings and client failure paths - #55
Conversation
Cover the three branches no test reached: a settings file that holds valid JSON but not an object, a settings file that cannot be written, and settings that TraceClient rejects with ValueError (a blank endpoint or an oversized TRACE_INSTALL_ID). Each is triggered with real input rather than a mock. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Self-review rubric (anchored on CI run 41176547278, which passed, and on a local run of 159 tests, all OK):
Inline notes:
The diff is review-ready. No do-not-auto-merge path is touched. This review comment was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener). drafted by Claude on behalf of Daniel Stephenson |
|
Correction to the self-review above: the two inline notes cite the wrong lines. The missing-directory setup is at This comment was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener). drafted by Claude on behalf of Daniel Stephenson |
Summary
Stage B (unit-test expansion) cycle. Characterization tests are added for the three error paths in
usage_reporting.pythat no test reached: coverage showed lines 94, 108–109 and 137–139 unexecuted. No production code is changed.test_settings_file_that_is_not_an_object_disables_reporting_without_raising: asettings.jsonthat holds valid JSON but not an object (["usage_reporting"]) makesloadSettingsreturnNoneand logsettings file is not a JSON object. The file is left untouched. This matches the README's statement that such a file "is left untouched, and nothing is reported for that run".test_unwritable_settings_file_still_returns_the_defaults_and_warns_once: when the settings file cannot be written (its directory does not exist), the default block is still returned, the first-run notice is followed by aCould not write …; the notice above will be shown again next time.message, and no file is created.test_settings_the_client_rejects_disable_reporting_without_raising: whenTraceClientraisesValueError,buildClientlogsCould not configure usage reporting (…)and returns a disabled client. Two real inputs trigger this: a whitespace-onlyendpoint, which is truthy and so bypasses theDEFAULT_ENDPOINTfallback, and aTRACE_INSTALL_IDlonger than 255 characters. No installation-ID file is created in either case.Every path is triggered with real input rather than a mock of the code under test.
Test plan
python3 -m unittest discover -s tests: 159 tests ran, OK (156 before, plus 3 new)python3 -m py_compileon every module listed in the CI workflow passesisinstance(settings, dict)guard toif False:, and narrowing each of the twoexceptclauses toexcept KeyError, made all three new tests error (4 subtest-level errors). Restoring the source returned them to green.python3 main.py 10 --exit-after-createagainst a live Viron) is UNVERIFIED-not-applicable: no rendering or Viron-service code is touched.Deferred issues
The tests stand without a tracking issue; the gap was found by coverage during triage. Open issues were not picked for these reasons:
Vironsubmodule requires explicit authorization.This PR description was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
🤖 Generated with Claude Code
drafted by Claude on behalf of Daniel Stephenson