You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the existing issues and haven't found one that matches what I'm reporting or requesting now.
If this is a bug report, I have searched the Bash changelog for information that may explain or provide clues to the behavior I'm observing and reference it in the body of the report.
Framework, Bash, and operating system version information
The function __assert_file that is used by file assertion functions sets the output and lines variables to the content of the file under test in order to take advantage of the other "regular" assert_ functions that operate on these variables. In a test, however, this does not allow the use of a "regular" assertion after a file assertion. For instance, the following will fail:
I tried to add around the main body of __assert_file an additional step of storing the output and lines variables if they are already set and then putting back their original values just before __assert_file exits (commented out lines below):
__assert_file() {
local assertion="$1"local file_path="$2"shift 2
local constraints=("$@")
# if [[ "${output-GO_SCRIPT_UNDEFINED}" != 'GO_SCRIPT_UNDEFINED' ]]; then# old_output="$output"# old_lines=("${lines[@]}")# fiif! set_bats_output_and_lines_from_file "$file_path";thenreturn'1'fiif [[ "$assertion"=='assert_matches' ]];thenif [[ "$#"-ne'1' ]];thenprintf'ERROR: %s takes exactly two arguments\n'"${FUNCNAME[1]}">&2return'1'fi
constraints=("$1""$output""The content of '$file_path'")
fi"$assertion""${constraints[@]}"# if [[ "${old_output-GO_SCRIPT_UNDEFINED}" != 'GO_SCRIPT_UNDEFINED' ]]; then# output="$old_output"# lines=("${old_lines[@]}")# fi
}
This works but some tests in tests/assertions.bats fail because they rely on the current behavior.
There are two workarounds this without the above change. First option, a test that uses the assert_file_* functions can store output somewhere safe before calling the assert_file_* function.
The second option would be to simply reorder the checks in the test function, so that file assertions go always last. In the above sample test, assert_output_matches should go before assert_file_matches. But this might be a bit counter-intuitive, depending on the application.
Both options require that the behavior is documented so that the developer knows what to do. But to me the best solution seems to be to fix __assert_lines.
The text was updated successfully, but these errors were encountered:
Due diligence
Framework, Bash, and operating system version information
Description
The function
__assert_file
that is used by file assertion functions sets theoutput
andlines
variables to the content of the file under test in order to take advantage of the other "regular"assert_
functions that operate on these variables. In a test, however, this does not allow the use of a "regular" assertion after a file assertion. For instance, the following will fail:I tried to add around the main body of
__assert_file
an additional step of storing theoutput
andlines
variables if they are already set and then putting back their original values just before__assert_file
exits (commented out lines below):This works but some tests in
tests/assertions.bats
fail because they rely on the current behavior.There are two workarounds this without the above change. First option, a test that uses the
assert_file_*
functions can storeoutput
somewhere safe before calling theassert_file_*
function.The second option would be to simply reorder the checks in the test function, so that file assertions go always last. In the above sample test,
assert_output_matches
should go beforeassert_file_matches
. But this might be a bit counter-intuitive, depending on the application.Both options require that the behavior is documented so that the developer knows what to do. But to me the best solution seems to be to fix
__assert_lines
.The text was updated successfully, but these errors were encountered: