Follow-up from Codex review on PR #116 (P2, tests/test_clauck_history_cost.py:242).
Problem
The assertion `self.assertIn("1", out)` for the `fails` column can pass even when failure accounting is broken. `cmd_cost` output contains "1" in many fields (run counts, cost totals, etc.), so the test is green whenever any cell contains the digit "1" — regardless of whether the `fails` column specifically holds the expected value.
Fix
Assert against the specific row structure. Options:
- Regex matching the job's row: `r"^\s*myjob\s+\d+\s+\\$\d+\.\d+\s+\\$\d+\.\d+\s+1\s+"`
- Split by lines, find the row that starts with the job name, split by whitespace, assert position[4] == "1".
- Parse the tabular output once with a helper and assert on a dict.
Option 3 is most robust for future test additions.
Acceptance
- Test fails when `fails` column logic regresses (simulate by mutating the sort/count function in a hypothetical branch).
- Test passes in the green case.
Follow-up from Codex review on PR #116 (P2, tests/test_clauck_history_cost.py:242).
Problem
The assertion `self.assertIn("1", out)` for the `fails` column can pass even when failure accounting is broken. `cmd_cost` output contains "1" in many fields (run counts, cost totals, etc.), so the test is green whenever any cell contains the digit "1" — regardless of whether the `fails` column specifically holds the expected value.
Fix
Assert against the specific row structure. Options:
Option 3 is most robust for future test additions.
Acceptance