What's wrong
tests/state-matrix.sh has two assertions added alongside the focus report
bash-3.2 fix (get_project_totals_in_range):
out=$(./focus report custom 90000 2>&1)
chk "report: multi-session project total" "0" \
"$([[ "$out" == *"rep/x"*"3h 0m"*"2 session"* ]]; echo $?)"
chk "report: single-session project total" "0" \
"$([[ "$out" == *"rep/y"*"30m"*"1 session"* ]]; echo $?)"
[[ ... ]] glob matching with * matches across newlines in bash, so this
only confirms the three substrings ("rep/x", "3h 0m", "2 session")
appear somewhere in that order across the whole multi-line report output —
not that "3h 0m" and "2 session" are on rep/x's own line.
It passes today only because rep/x (3h total) sorts first via
ORDER BY SUM(duration_seconds) DESC, so its own numbers happen to be the
first match encountered. That's incidental, not verified.
Impact
A regression that attributed one project's total/session-count to a
different project's printed line — e.g. a column-mapping bug in the
per-project loop, or a bad printf format reorder — would only be caught by
this test if the swapped numbers also happened to break the substring
ordering, which isn't guaranteed. Nothing else in the suite inspects the
Projects: section's content.
This does not block any current verification of correctness. The
underlying aggregation (get_project_totals_in_range's WHERE-clause parity
with list_sessions_in_range, and correct SUM/COUNT/GROUP BY behavior
including duration-only rows) was independently verified two other ways: a
live test with mixed timed + duration-only sessions in the same project, and
direct comparison of the two SQL functions' WHERE clauses. This is a gap in
the regression safety net for a narrow future bug class, not a hole in
current correctness.
Fix
Anchor the assertions to the actual line instead of the whole output, e.g.:
chk "report: multi-session project total" "0" \
"$([[ "$out" =~ ^[[:space:]]*rep/x[[:space:]]+3h\ 0m\ \(2\ session ]]; echo $?)"
or the equivalent with grep -qE '^ *rep/x .*3h 0m \(2 session'.
Location
tests/state-matrix.sh, in the "report: bash-3.2 compat" section (search for
"report: multi-session project total").
What's wrong
tests/state-matrix.shhas two assertions added alongside thefocus reportbash-3.2 fix (
get_project_totals_in_range):[[ ... ]]glob matching with*matches across newlines in bash, so thisonly confirms the three substrings (
"rep/x","3h 0m","2 session")appear somewhere in that order across the whole multi-line report output —
not that
"3h 0m"and"2 session"are onrep/x's own line.It passes today only because
rep/x(3h total) sorts first viaORDER BY SUM(duration_seconds) DESC, so its own numbers happen to be thefirst match encountered. That's incidental, not verified.
Impact
A regression that attributed one project's total/session-count to a
different project's printed line — e.g. a column-mapping bug in the
per-project loop, or a bad
printfformat reorder — would only be caught bythis test if the swapped numbers also happened to break the substring
ordering, which isn't guaranteed. Nothing else in the suite inspects the
Projects:section's content.This does not block any current verification of correctness. The
underlying aggregation (
get_project_totals_in_range's WHERE-clause paritywith
list_sessions_in_range, and correct SUM/COUNT/GROUP BY behaviorincluding duration-only rows) was independently verified two other ways: a
live test with mixed timed + duration-only sessions in the same project, and
direct comparison of the two SQL functions' WHERE clauses. This is a gap in
the regression safety net for a narrow future bug class, not a hole in
current correctness.
Fix
Anchor the assertions to the actual line instead of the whole output, e.g.:
or the equivalent with
grep -qE '^ *rep/x .*3h 0m \(2 session'.Location
tests/state-matrix.sh, in the "report: bash-3.2 compat" section (search for"report: multi-session project total").