docs(patterns): stop showing assertions that can never fail by Chemaclass · Pull Request #1212 · TypedDevs/bashunit

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass · 2026-08-14T05:28:50Z

🤔 Background

Related #1211

assert_successful_code / assert_general_error read $? and do not run a
string handed to them. Seven examples in the guide users copy from passed one
anyway, so the assertion could never fail:

assert_successful_code "false" ✓ Passed
assert_successful_code "definitely_not_a_command_xyz" ✓ Passed

A copied "test the server responds to ping" test verified nothing. Worse than
#1209, where swapped arguments at least failed loudly.

💡 Changes

Replace the seven with assert_exec, which executes the string and — since fix(assert): let assert_exec assert a non-zero exit under --strict #1208 — handles a non-zero exit under --strict. Verified with shell functions, a pipeline, and both modes

Deliberately left alone

assert_successful_code "$(sync_with_the_api)" elsewhere is correct: the
substitution runs the command, so $? carries. Both shapes executed to confirm:

shape	failing command
`"$(failing_fn)"`	✗ Failed — correct
`"failing_fn"`	✓ Passed — vacuous

assert_successful_code and assert_general_error read $?; they do not run a string handed to them, as assertions.md states. Seven examples passed a command string anyway, so the string was ignored, $? was 0, and the assertion could never fail: assert_successful_code "false" passes assert_successful_code "definitely_not_a_command_xyz" passes A copied 'test the server responds' test therefore verified nothing. Worse than the swapped arguments in #1209, which at least failed loudly. Replaced with assert_exec, which executes the string and, since #1208, handles a non-zero exit under --strict. Verified with shell functions, a pipeline and both modes. The "$(cmd)" forms in test-files.md, skipping-incomplete.md and test-doubles.md are correct -- the substitution runs the command so $? carries -- and are left alone. Both shapes were executed to confirm the difference. Closes#1211

Chemaclass added the documentation Improvements or additions to documentation label Aug 14, 2026

Chemaclass self-assigned this Aug 14, 2026

Chemaclass merged commit ca7d7d3 into mainAug 14, 2026
6 checks passed