Forum: RSpec Having a problem with new webrat matchers in cucumber 2

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
James B. (Guest)
on 2009-03-20 15:45
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.
Aslak H. (Guest)
on 2009-03-20 16:50
(Received via mailing list)
On Fri, Mar 20, 2009 at 9:45 AM, James B. <removed_email_address@domain.invalid>
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. (Guest)
on 2009-03-20 17:42
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
James B. (Guest)
on 2009-03-20 17:52
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.
Pat M. (Guest)
on 2009-03-20 18:48
(Received via mailing list)
> 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
David C. (Guest)
on 2009-03-20 18:55
(Received via mailing list)
On Fri, Mar 20, 2009 at 10:52 AM, James B. 
<removed_email_address@domain.invalid>
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!
David C. (Guest)
on 2009-03-20 19:01
(Received via mailing list)
On Fri, Mar 20, 2009 at 11:23 AM, Pat M. <removed_email_address@domain.invalid>
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 M. (Guest)
on 2009-03-20 19:24
(Received via mailing list)
On Fri, Mar 20, 2009 at 9:53 AM, David C. <removed_email_address@domain.invalid>
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
James B. (Guest)
on 2009-03-20 20:49
David C. 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
This topic is locked and can not be replied to.