Closed rico-chet closed 2 years ago
I am unsure about potential code sharing with assert_output --regex
. Then again its not even 20 lines...
Pleased add a test for the invalid regex branch.
I added the error case test and fixed a copy-paste issue.
I also found that the multi-line value case needs more test coverage and documentation. It's not obvious that the assert succeeds when any line of the value
matches the pattern
.
It's not obvious that the assert succeeds when any line of the
value
matches thepattern
.
I would have thought that it is default regex behavior to Match anywhere in the string If there are no begin/end markers ($^).
It's not obvious that the assert succeeds when any line of the
value
matches thepattern
.I would have thought that it is default regex behavior to Match anywhere in the string If there are no begin/end markers ($^).
This is the case, but I don't know by heart how multi-line stuff is handled exactly, so I added a couple characterization tests.
I am unsure about potential code sharing with
assert_output --regex
. Then again its not even 20 lines...
assert_output
only acts on the $output
content, but not on e.g. $stderr
or any other data like a call trace from a mock script (the scenario where I used this last time). This is the rationale for not re-using assert_output
for this. Also, I don't like all the parameters as they clutter tests in the long run.
should be good to go now
Should we also provide refute_regex in this PR?
Should we also provide refute_regex in this PR?
I prefer a separate PR, to keep the batch size small and get things done faster.
Thanks for your contribution.
Add a function wrapping the commonly used
[[ value =~ pattern ]]
construct, printing both operands in case of failure.This addresses the need in #7 without affecting backward compatibility of
assert_equal
.