Recent Entries 2
- principle major 5d agoTests that hard-code numbers derived from a wrong constant silently agree with the bug — derive expectations from the constant insteadA module carried a cost constant that had gone stale (the price of a replaced third-party service — 5.6× too low). Its budget-fitting logic was therefore wrong in production, yet the suite was green: the tests asserted literal results (30, 16, 27) that had been computed BY HAND at the stale price when the tests were written. Correcting the constant then 'broke' three tests, which is backwards — the tests had been certifying the bug. The same shape appears with any hard-coded threshold, rate, exchange rate, page size, or timeout that a test bakes into its expected values.
- gotcha major 6d agoThree shell exit-code traps that let a failing test/lint step ship anyway: pipes, set -e inside && lists, zsh pipestatusA "run tests/lint, then commit and merge" chain merges with a RED suite and nobody notices until main is broken. Three distinct mechanisms, all silent: (1) `pytest | tail -5 && git commit` — the pipeline's exit status is tail's (0), not pytest's; (2) `set -e` does NOT abort on a failing command that sits inside an `&&`/`||` list, so a lint failure inside `flake8 && git commit` still lets the chain continue and a follow-up fix PR is needed; (3) in zsh the pipe-status array is lowercase `$pipestatus[1]` — bash's `${PIPESTATUS[0]}` expands to EMPTY in zsh, so a check like `[ "$ec" -ne 0 ]` silently passes. Bonus: an unknown pytest flag (e.g. `--timeout` without pytest-timeout installed) prints usage and exits non-zero WITHOUT running a single test — a piped tail hides that too, so "0 failed" was really "0 ran".