-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require STDIN to be specified explicitly with -
#14
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the additional cleanup work too!
run echo 'a' | ||
run refute_output <<INPUT | ||
@test 'refute_output() - : reads <unexpected> from STDIN' { | ||
run echo '-' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you change the run
command? As far as I can tell, it worked with run echo 'a'
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a stronger assertion that -
as input on stdin doesn't cause problems. (Since the -
is also the flag to the assertion)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay got it. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor changes and ready to merge.
@@ -185,12 +185,14 @@ assert_failure() { | |||
assert_output() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update the function comment too? For example:
# Options:
# -p, --partial - partial matching
# -e, --regexp - extended regular expression matching
+# - - read expected output from the standard input
# Arguments:
-# $1 - [=STDIN] expected output
+# $1 - expected output
# Returns:
# 0 - expected matches the actual output
# 1 - otherwise
@@ -278,12 +282,14 @@ assert_output() { | |||
refute_output() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update the function comment too? For example:
# Options:
# -p, --partial - partial matching
# -e, --regexp - extended regular expression matching
+# - - read unexpected output from the standard input
# Arguments:
-# $1 - [=STDIN] unexpected output
+# $1 - unexpected output
# Returns:
# 0 - unexpected matches the actual output
# 1 - otherwise
|
||
# Handle options. | ||
while (( $# > 0 )); do | ||
case "$1" in | ||
-p|--partial) is_mode_partial=1; shift ;; | ||
-e|--regexp) is_mode_regexp=1; shift ;; | ||
-) use_stdin=1; shift ;; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking a long option, e.g. --stdin
, would be nice. Safe for refute_output
. What do you think?
Updated comments and added --stdin longform option to both |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs a few more simple changes and ready to go!
@@ -189,12 +189,13 @@ By default, literal matching is performed. The assertion fails if | |||
} | |||
``` | |||
|
|||
The expected output can be specified with a heredoc or standard input as well. | |||
The expected output can be specified with a heredoc or standard input as well, | |||
by providing `-` as an option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you mention the long option in the README as well. Like we did for other options:
Partial matching can be enabled with the
--partial
option (-p
for short). When used, the assertion fails if the expected substring is not found in$output
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added! 581aa70
@@ -287,12 +288,13 @@ By default, literal matching is performed. The assertion fails if | |||
} | |||
``` | |||
|
|||
-The unexpected output can be specified with a heredoc or standard input as well. | |||
The unexpected output can be specified with a heredoc or standard input as well, | |||
by providing `-` as an option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you mention the long option in the README as well. Like we did for other options:
Partial matching can be enabled with the
--partial
option (-p
for short). When used, the assertion fails if the expected substring is not found in$output
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added! 581aa70
@@ -26,9 +26,19 @@ load test_helper | |||
[ "${lines[3]}" == '--' ] | |||
} | |||
|
|||
@test 'assert_output(): reads <expected> from STDIN' { | |||
@test 'assert_output() - : reads <expected> from STDIN' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please factor out common parts of tests to avoid duplicating code. Like it's done here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually have a strong dislike of that extraction. Generally I favor non-dry tests because tests should be explicit and self-contained. In this case (and with test_r_regexp
), it's quite difficult to understand what's going on with the extracted function. Instead of the test functioning as example usage, we now have variables (unnamed vars at that) being used in place of the very thing that makes the test unique.
If anything should be extracted, I'd extract the duplicated assertions from all tests:
[ "$status" -eq 0 ]
[ "${#lines[@]}" -eq 0 ]
The implementation of those statements are not germane to the test, so abstracting them away can improve readability. However, extracting away the actual invocation is a bad idea, IMO. The unique invocation is literally the raison d'être for the test(s).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened a PR to this PR to show usage of just the assertion helper rather than attempting to dry up the entire test(s).
run assert_output - <<STDIN | ||
a | ||
STDIN | ||
echo "$output" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leftover debug print.
|
||
@test 'assert_output() --stdin : reads <expected> from STDIN' { | ||
run echo 'a' | ||
run assert_output --stdin <<STDIN | ||
a | ||
STDIN | ||
echo "$output" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove this debug print left over from a previous PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done adc1c7b
Merged this branch in my fork: bats-core@658b73a |
First step for #5