2024-05-28 19:43:04 +03:00
#!/usr/bin/env bash
2021-12-09 17:26:46 +02:00
# Test the functions for testing themselves!
# Also test some assumptions on how bash works that they rely on.
source common.sh
# `true` should exit with 0
expect 0 true
# `false` should exit with 1
expect 1 false
# `expect` will fail when we get it wrong
expect 1 expect 0 false
2024-07-16 02:28:28 +03:00
function ret( ) {
return $1
}
# `expect` can call functions, not just executables
expect 0 ret 0
expect 1 ret 1
# `expect` supports negative exit codes
expect -1 ret -1
# or high positive ones, equivalent to negative ones
expect 255 ret 255
expect 255 ret -1
expect -1 ret 255
# but it doesn't confuse negative exit codes with positive ones
expect 1 expect -10 ret 10
2021-12-09 17:26:46 +02:00
noisyTrue ( ) {
echo YAY! >& 2
true
}
noisyFalse ( ) {
echo NAY! >& 2
false
}
# These should redirect standard error to standard output
expectStderr 0 noisyTrue | grepQuiet YAY
expectStderr 1 noisyFalse | grepQuiet NAY
# `set -o pipefile` is enabled
pipefailure ( ) {
# shellcheck disable=SC2216
true | false | true
}
expect 1 pipefailure
unset pipefailure
pipefailure ( ) {
# shellcheck disable=SC2216
false | true | true
}
expect 1 pipefailure
unset pipefailure
commandSubstitutionPipeFailure ( ) {
# shellcheck disable=SC2216
res = $( set -eu -o pipefail; false | true | echo 0)
}
expect 1 commandSubstitutionPipeFailure
# `set -u` is enabled
# note (...), making function use subshell, as unbound variable errors
# in the outer shell are *rightly* not recoverable.
useUnbound ( ) (
set -eu
# shellcheck disable=SC2154
echo " $thisVariableIsNotBound "
)
expect 1 useUnbound
# ! alone unfortunately negates `set -e`, but it works in functions:
# shellcheck disable=SC2251
! true
funBang ( ) {
! true
}
expect 1 funBang
unset funBang
2024-07-16 02:40:14 +03:00
# callerPrefix can be used by the test framework to improve error messages
# it reports about our call site here
echo " <[ $( callerPrefix) ]> " | grepQuiet -F " <[test-infra.sh: $LINENO : ]> "
2021-12-09 17:26:46 +02:00
# `grep -v -q` is not what we want for exit codes, but `grepInverse` is
# Avoid `grep -v -q`. The following line proves the point, and if it fails,
# we'll know that `grep` had a breaking change or `-v -q` may not be portable.
{ echo foo; echo bar; } | grep -v -q foo
{ echo foo; echo bar; } | expect 1 grepInverse foo
# `grepQuiet` is quiet
res = $( set -eu -o pipefail; echo foo | grepQuiet foo | wc -c)
( ( res = = 0 ) )
unset res
# `greqQietInverse` is both
{ echo foo; echo bar; } | expect 1 grepQuietInverse foo
res = $( set -eu -o pipefail; echo foo | expect 1 grepQuietInverse foo | wc -c)
( ( res = = 0 ) )
unset res
2024-07-16 02:41:22 +03:00
# `grepQuiet` does not allow newlines in its arguments, because grep quietly
# treats them as multiple queries.
2024-07-25 16:38:02 +03:00
{ echo foo; echo bar; } | expectStderr -101 grepQuiet $'foo\nbar' \
2024-07-16 02:41:22 +03:00
| grepQuiet -E 'test-infra\.sh:[0-9]+: in call to grepQuiet: newline not allowed in arguments; grep would try each line individually as if connected by an OR operator'
2024-07-16 02:54:12 +03:00
# We took the blue pill and woke up in a world where `grep` is moderately safe.
expectStderr -101 grep $'foo\nbar' \
| grepQuiet -E 'test-infra\.sh:[0-9]+: in call to grep: newline not allowed in arguments; grep would try each line individually as if connected by an OR operator'