I ran script/generate cucumber and since then I am having a few
difficulties. For instance, take this case:
When /see (?:an|the) authori(?:s|z)ation required message/ do
Then “I should see “You are not authori(?:s|z)ed””
end
Now gives:
And they should see an authorization required message
# features/app/step_definitions/authorization_steps.rb:1
expected the following element's content to include
"You are not authori(?:s|z)ed":
…
You are not authorized to access the requested resource
This matcher worked perfectly well in cucumber up to and including v
0.2.0, until after I ran script/generate cucumber. The problem seems to
be the substitution in webrat_steps.rb of:
response.should contain(text)
for
response.body.should =~ /#{text}/m
I have reverted to the old style matcher which solves my immediate
problem. My question is: Was subpattern matching deliberately removed
from this matcher or is this an error?
P.S. This is Canada and up here both ‘ise’ (UK) and ‘ize’ (US) endings
are commonly used. However, generally those who choose one despise those
who choose the other. So as to have peace over a triviality I provide
for both.
On Fri, Mar 20, 2009 at 9:45 AM, James B. [email protected]
wrote:
And they should see an authorization required message
response.should contain(text)
for
response.body.should =~ /#{text}/m
We switched to using response.should contain(text) a while back. This is
just a wrapper around Rails’ assert_contain, the preferred (I think) way
to
check for text on a page.
I’m not sure what Cucumber version you’re on.
Aslak
James B. wrote:
Aslak Hellesøy wrote:
We switched to using response.should contain(text) a while back. This is
just a wrapper around Rails’ assert_contain, the preferred (I think) way
to check for text on a page.
I am thinking that you are right. This particular feature was written
back when I was first starting out with cucumber, features and steps and
BDD. I have since taken to checking for specific css ids relating to
messages and notices in steps rather than looking for the text itself.
I likely will refactor this step to do the same.
I think, if it is not already on the wiki, that cucumber users might be
encouraged to put any local additions to support/env.rb into a separate
file like support/local_env.rb. Running script/generate cucumber to
upgrade an existing project leaves those with customized env.rb files
with two equally unappealing alternatives; keep the old and forgo the
new or replace it entirely.
I think, if it is not already on the wiki, that cucumber users might be
encouraged to put any local additions to support/env.rb into a separate
file like support/local_env.rb. Running script/generate cucumber to
upgrade an existing project leaves those with customized env.rb files
with two equally unappealing alternatives; keep the old and forgo the
new or replace it entirely.
Or overwrite the file and use git diff to see what was removed, and
add it back in.
Pat
On Fri, Mar 20, 2009 at 10:52 AM, James B. [email protected]
wrote:
messages and notices in steps rather than looking for the text itself.
I likely will refactor this step to do the same.
I think, if it is not already on the wiki, that cucumber users might be
encouraged to put any local additions to support/env.rb into a separate
file like support/local_env.rb. Running script/generate cucumber to
upgrade an existing project leaves those with customized env.rb files
with two equally unappealing alternatives; keep the old and forgo the
new or replace it entirely.
James - I think this is a good idea. Would you kindly post a ticket to
lighthouse:
http://rspec.lighthouseapp.com/projects/16211
Thanks!
On Fri, Mar 20, 2009 at 11:23 AM, Pat M. [email protected]
wrote:
I think, if it is not already on the wiki, that cucumber users might be
encouraged to put any local additions to support/env.rb into a separate
file like support/local_env.rb. Running script/generate cucumber to
upgrade an existing project leaves those with customized env.rb files
with two equally unappealing alternatives; keep the old and forgo the
new or replace it entirely.
Or overwrite the file and use git diff to see what was removed, and
add it back in.
Pat - this is a common problem w/ upgrading rspec-rails too - I asked
James to file the ticket so we could coordinate on approach w/ cuc and
rspec.
Make sense to you?
On Fri, Mar 20, 2009 at 9:53 AM, David C. [email protected]
wrote:
Pat - this is a common problem w/ upgrading rspec-rails too - I asked
James to file the ticket so we could coordinate on approach w/ cuc and
rspec.
Make sense to you?
Generally I have some stuff that I have to require before the rspec
config block loads. I think that splitting everything into two
files would cause problems with certain dependencies, but that may be
something I just have to work out.
Pat