Repository navigation
test(report): make color helpers testable and add colour-output tests - #7
Conversation
Turns the module-level `useColor` constant into a function that re-reads the environment, which is what made the coloured paths testable at all. Branch coverage on report.ts goes from ~62% to ~97%: NO_COLOR, TERM=dumb, non-TTY (the CI case) and TTY are all exercised, for both finding types and for summaries. Verified locally against current main: 130 tests pass and no other file's coverage regressed. Closes #4
|
Merged into I validated it locally against current
Two adjustments I made on top, both explained in the merge commit:
Removed The refactor itself is exactly right. Making Released in v0.5.1. |
Problem
src/report.tshas the colour-check logic as a module-level constant computed once at import time:This makes it impossible to test the coloured code paths by mutating
process.env.NO_COLOR,process.env.TERM, orprocess.stderr.isTTYinside a test — the value is already frozen. Current branch coverage onreport.tsis only ~62%, and the coloured path is entirely untested.Fix
Refactor: Convert
useColorfrom a module-levelconstinto a function that re-reads the environment on every call. This is trivially testable — each test can mutate env / stubisTTYand the functions see the new values.The refactoring itself is minimal (move the boolean expression into
useColor()and update the fivec.*helpers to call it). A no-op_resetColorState()export is also added as a coordination hook for future tests that may need it.Test Plan
npm test)test/report.test.ts— 6 tests covering:NO_COLORset → no escape codesTERM=dumb→ no escape codesisTTY=false(CI case) → no escape codesn_plus_oneandduplicatefindings with/without coloursreport.jsimproved from ~62% to ~97%Testing
Closes #4