rspec users - Mar 2009 - Having a problem with new webrat matchers in cucumber 2

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.
-- 
Posted via http://www.ruby-forum.com/.

On Fri, Mar 20, 2009 at 9:45 AM, James Byrne <lists at ruby-forum.com>
wrote:
> 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
>
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
>
> 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.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090320/f6cc2a58/attachment.html>

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''m not sure what Cucumber version you''re on.
> 
> Aslak
V 0.2.0
-- 
Posted via http://www.ruby-forum.com/.

James Byrne 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.
-- 
Posted via http://www.ruby-forum.com/.

> 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 Byrne <lists at ruby-forum.com>
wrote:
> James Byrne 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.
James - I think this is a good idea. Would you kindly post a ticket to
lighthouse:

http://rspec.lighthouseapp.com/projects/16211

Thanks!
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Fri, Mar 20, 2009 at 11:23 AM, Pat Maddox <pat.maddox at gmail.com>
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?
>
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Fri, Mar 20, 2009 at 9:53 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On Fri, Mar 20, 2009 at 11:23 AM, Pat Maddox <pat.maddox at
gmail.com> 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?
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

David Chelimsky wrote:
> 
> James - I think this is a good idea. Would you kindly post a ticket to
> lighthouse:
> 
> http://rspec.lighthouseapp.com/projects/16211
> 
> Thanks!
ticket #253
-- 
Posted via http://www.ruby-forum.com/.