fix(doubles): a non-numeric spy count leaked a raw shell error

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.

[Chemaclass]

🤔 Background

Related #984

assert_have_been_called_times my_cmd 1

./src/doubles/assertions.sh: line 180: [: my_cmd: integer expression expected

The count reached [ "$times" -ne "$expected_count" ] unchecked, so bash printed a diagnostic naming bashunit's own source file and line. The user's mistake was swapping two arguments; what they were shown was the framework's internals. assert_have_been_called_nth_with had the identical exposure on $nth.

💡 Changes

Both now report a usage error through the channel #989 introduced, naming the argument order that was got wrong:

assert_have_been_called_times expects a numeric count first (expected_count, command), got 'my_cmd'

The guard runs before the spy lookup, deliberately. Placed after it, a swapped call was diagnosed as '1' was never registered as a spy — true, and a symptom. The ordering mistake is the cause, and naming it directly is what turns the failure into an instruction.

✅ What the issue asked for that was already done

Checked before writing anything, rather than assumed:

• docs/assertions.mdalready cross-references the order difference from both entries ("the spy comes first here, but second in assert_have_been_called_times")
• the existing fail_unregistered path already names what was read as the spy

The only gap left was the crash, so that's all this changes.

🔒 Verification

1 new acceptance test, RED first. make sa · make lint · bash build.sh bin -v → ✅ Build verified ✅ · 1706 sequential / 1665 parallel-simple-strict.