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'd like my cucumber features to be able to match slashes in the file content, like so:
Then the file named "vcs/cmdline" should not match %r</home/scottj/foo\.v>
This fails today because the step definition at lib/aruba/cucumber/file.rb:159 disallows slashes, for no apparent reason:
Then(/^(?:a|the) file(?: named)? "([^"]*)" should (not )?match %r<([^\/]*)>$/) do |file, negated, content|
I assume this is a copy-paste mistake from the next matcher which uses slashes instead of %r<> to delineate the regexp.
Expected Behavior
The Then step definition in file.rb:159 should match the feature line shown above.
Current Behavior
No step definition matches, and my features fail:
You can implement step definitions for undefined steps with these snippets:
...etc...
Possible Solution
I have a commit that fixes it for me, but I'm unable to properly test it because (following the instructions in CONTRIBUTING) I get massive failures from cucumber before making any change in my repo.
The diff:
diff --git a/lib/aruba/cucumber/file.rb b/lib/aruba/cucumber/file.rb
index 3b8e3f4..801bfbd 100644
--- a/lib/aruba/cucumber/file.rb
+++ b/lib/aruba/cucumber/file.rb
@@ -156,7 +156,7 @@ Then(/^(?:a|the) file(?: named)? "([^"]*)" should (not )?contain exactly:$/) do
end
end
-Then(/^(?:a|the) file(?: named)? "([^"]*)" should (not )?match %r<([^\/]*)>$/) do |file, negated, content|
+Then(/^(?:a|the) file(?: named)? "([^"]*)" should (not )?match %r<([^>]*)>$/) do |file, negated, content|
if negated
expect(file).not_to have_file_content file_content_matching(content)
else
I'm not sure if the [^>]* is really necessary or if it could be simply .*.
Steps to Reproduce (for bugs)
Create a feature with the line shown above; to repeat:
Then the file named "vcs/cmdline" should not match %r</home/scottj/foo\.v>
This should work without having to write any custom step definitions for cucumber.
Context & Motivation
I'm trying to match pathnames that should or should not be in certain files output by the program I'm testing. Without being able to match slashes, I have to use . instead, making the features unnecessarily confusing, hard to read, and hard to write.
Your Environment
Version used: 0.14.2, also in current github master
The text was updated successfully, but these errors were encountered:
@scottj97 can you rebase your commit on current master and create a pull request? The massive build failures have been fixed so testing your commit should work smoothly now.
stalebot
removed
the
stale
These issues were closed by stalebot and need to be reviewed to see if they're still relevant.
label
Nov 10, 2017
Summary
I'd like my cucumber features to be able to match slashes in the file content, like so:
This fails today because the step definition at lib/aruba/cucumber/file.rb:159 disallows slashes, for no apparent reason:
I assume this is a copy-paste mistake from the next matcher which uses slashes instead of
%r<>
to delineate the regexp.Expected Behavior
The Then step definition in file.rb:159 should match the feature line shown above.
Current Behavior
No step definition matches, and my features fail:
Possible Solution
I have a commit that fixes it for me, but I'm unable to properly test it because (following the instructions in CONTRIBUTING) I get massive failures from cucumber before making any change in my repo.
The diff:
I'm not sure if the
[^>]*
is really necessary or if it could be simply.*
.Steps to Reproduce (for bugs)
Create a feature with the line shown above; to repeat:
This should work without having to write any custom step definitions for cucumber.
Context & Motivation
I'm trying to match pathnames that should or should not be in certain files output by the program I'm testing. Without being able to match slashes, I have to use
.
instead, making the features unnecessarily confusing, hard to read, and hard to write.Your Environment
The text was updated successfully, but these errors were encountered: