Standalone
You can use all bashunit assertions outside any tests if you would like to use them in integration or end-to-end tests, for entire applications or executables.
Executing an assertion
If you want to use the nice assertions syntax of bashunit - without the tests context/functions, but to end-to-end tests executables, you can use the -a|--assert option when running ./bashunit and call the assertion directly from there.
The return exit code will be:
0success assertion1failed assertion127non-existing function
INFO
The prefix assert_ is optional.
# with `assert_` prefix
./bashunit -a assert_same "foo" "foo"
# or without prefix
./bashunit -a equals "foo" "foo"# No output - exit code 0 (success)# with `assert_` prefix
./bashunit -a assert_not_equals "foo" "foo"
# or without prefix
./bashunit -a not_equals "foo" "foo"✗ Failed: Main::exec not_equals
Expected 'foo'
but got 'foo'Lazy evaluations
You can evaluate the exit_code for your scripts using the command to call as raw-string instead of executing them with $(...) to avoid interrupting the CI when encountering a potential error (anything but 0).
./bashunit -a exit_code "1" "$PHPSTAN_PATH analyze \
--no-progress --level 8 \
--error-format raw ./"Testing.php:3:Method Testing::bar() has no return type specified.This is useful to get control over the output of your "callable":
OUTPUT=$(./bashunit -a exit_code "1" "$PHPSTAN_PATH analyze \
--no-progress --level 8 \
--error-format raw ./")
./bashunit -a line_count 1 "$OUTPUT"# No outputFull control over the stdout and stderr
The stdout will be used for the callable result, while bashunit output will be on stderr. This way you can control the FD and redirect the output as you need.
./bashunit -a exit_code "0" "$PHPSTAN_PATH analyze \
--no-progress --level 8 \
--error-format raw ./" 2> /tmp/error.logTesting.php:3:Method Testing::bar() has no return type specified.✗ Failed: Main::exec assert
Expected '0'
but got '1'