feat(assert): a composed assertion should count and report once by Chemaclass · Pull Request #921 · TypedDevs/bashunit

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917

Chemaclass · 2026-07-29T05:09:19Z

🤔 Background

Related #917

A custom assertion composed from built-in ones counts one assertion per inner step, and its failure names that step rather than the check the test author wrote — assert_http_success reported 2 assertions per call and failed with Expected '500' to be less than '300'.

The issue proposed an implicit nesting-depth counter. Verified on main, that does not work: the inner assertions are siblings, not nested — the first has already returned when the second starts, so both read depth 0. Detecting the enclosing assert_* frame instead would classify the inner assertion of assert_assertion_fails (#916) as nested and silence the counters its verdict detection reads, and would shift the totals of every suite already composing assertions. So this ships as an opt-in marker.

💡 Changes

Add bashunit::assert_once <label> <actual>: declared at the top of a custom assertion, it absorbs everything asserted inside into one reported assertion, labelled with the calling test.
Opt-in, so no existing totals change, assert_assertion_* keeps working, and repeated calls from a loop still count once each.
Bash has no cheap return hook, so the marker counts optimistically and the flush converts to a failure — totals stay correct at every point without observing the frame return.
Absorption hooks sit behind a plain global test in the four reporting choke points, keeping the per-assertion path flat.

… once A custom assertion built out of built-in assertions counts one assertion per inner step, and its failure names that step rather than the check the test author wrote. `assert_http_success` composed from two comparisons reported 2 assertions per call and failed with "Expected '500' to be less than '300'". Add an opt-in marker: `bashunit::assert_once <label> <actual>` at the top of a custom assertion absorbs everything it asserts into a single reported assertion, labelled with the test that called it. The issue proposed an implicit nesting-depth counter. That does not work here: the inner assertions are siblings, not nested frames -- the first has already returned when the second starts, so both read depth 0. What distinguishes composed from direct is an enclosing assert_* frame, and detecting that implicitly would classify the inner assertion of assert_assertion_fails (#916) as nested, silencing the very counters its verdict detection reads. An implicit rule would also shift the totals of every suite already composing assertions. Bash gives no cheap hook on a user function's return, so the marker counts one passing assertion immediately and the flush converts it to a failure if anything it absorbed failed. Totals are therefore correct at every point in time without ever observing the declaring frame return. The marker is settled by the next assert_once call (which is what makes a loop count once per iteration), by an assertion reached after the declaring frame returned, or by the end of the test. The end-of-test flush runs from the EXIT trap, where the test frame is gone, so the label is resolved eagerly at declaration time; otherwise failures were reported as "Bashunit::assert::once flush". Absorption hooks live in state::add_assertions_passed, assert::mark_failed, console_results::print_failed_test and ::print_failure_message, each behind a plain global test so the per-assertion path stays flat. assert::_capture saves and restores the whole marker so #916 keeps working around it. Closes#917