feat(assert): add numeric range assertions by w3lld1 · Pull Request #1037 · TypedDevs/bashunit

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

w3lld1 · 2026-08-10T11:23:30Z

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
I return usage errors for missing arguments, non-numeric values, and reversed bounds.
I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
make sa
make lint
git diff --check

Checklist

I updated the CHANGELOG.md to reflect the new feature or fix
I updated the documentation to reflect the changes

Fixes#1026

assert_between and assert_not_between accept a leading + on any operand, but operands wider than the fork-free fixed-point path fall through to bc, which cannot parse one: it answers with a parse error on stderr and an empty result, read here as "greater than". assert_within_delta already stripped the sign for the same reason; is_le now does it for every caller. Also pins the _is_numeric hardening this branch introduced: 1.2.3 and 5-3 now report as non-numeric instead of leaking a bc parse error or being evaluated as an expression.

Chemaclass

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.

# Conflicts: # CHANGELOG.md

feat(assert): add numeric range assertions
66692d9

Chemaclass assigned w3lld1 Aug 10, 2026

Chemaclass added the enhancement New feature or request label Aug 10, 2026