Forum: RSpec Just trying out cucumber

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.
Shane M. (Guest)
on 2008-11-24 18:11
(Received via mailing list)
Hi

Just giving cucumber a trial with a Rails application and was wanting
some feedback on what I did for my project token that is a system
generated value ....

   Scenario: Register new project
     Given I am logged in
     And I am on the new project page
     When I fill in "Title" with "My project title"
     And I fill in "Description" with "My project description"
     And I press "Create"
     Then I should see "My project title"
     And I should see "My project description"
     And "Project" "token" should have a value


Then /^"(.*)" "(.*)" should have a value$/ do |model, attribute|
   model = controller.instance_variable_get("@#{model.downcase}")
   model.send(attribute).should_not be_nil
end

Wasn't too sure how else this should be approached?

Cheers
Shane

Shane M.
ELC Technologies (TM)
1921 State Street
Santa Barbara, CA 93101


Phone: +64 4 568 6684
Mobile: +64 21 435 586
Email:  removed_email_address@domain.invalid
AIM:     ShaneMingins
Skype: shane.mingins

(866) 863-7365 Tel - Santa Barbara Office
(866) 893-1902 Fax - Santa Barbara Office

+44 020 7504 1346 Tel - London Office
+44 020 7504 1347 Fax - London Office

http://www.elctech.com
Pau C. (Guest)
on 2008-11-24 21:37
Shane M. wrote:
> Hi
>
> Just giving cucumber a trial with a Rails application and was wanting
> some feedback on what I did for my project token that is a system
> generated value ....
>
>    Scenario: Register new project
>      Given I am logged in
>      And I am on the new project page
>      When I fill in "Title" with "My project title"
>      And I fill in "Description" with "My project description"
>      And I press "Create"
>      Then I should see "My project title"
>      And I should see "My project description"
>      And "Project" "token" should have a value
>
>
> Then /^"(.*)" "(.*)" should have a value$/ do |model, attribute|
>    model = controller.instance_variable_get("@#{model.downcase}")
>    model.send(attribute).should_not be_nil
> end

This verifies that @project.token is set. If you are using active
record, then you can probably be fairly certain that the value is stored
in the database. If that is what you need to verify for the customer,
then that is fine.

However, customers don't (or shouldn't) care about the backend stuff
like ActiveRecord objects and database records. For that reason, I'd be
more inclined to make sure the project token was displayed on the
screen--that is something the customer interacts with and should care
about. So that would mean a matcher that is something like this:

Then /^"(.*)" "(.*)" should have a value$/ do |model, attribute|
  response.body.should =~
/\<div\s[\w=\"\']*id\=\"#{model.downcase}_#{attribute}\"\>#{model}#{SOME_REGEX_THAT_MATCHER_YOUR_TOKEN}/m
end

I haven't tested that, so it is probably broken. But the point of the
regex is to match a div with the id model_attribute (change this if you
set ids with a different convention) and it should have the contents
"Token MYTOKEN".

If you do this, you are verifying what the customer actually sees, which
i _generally_ find preferable to verifying some backend thing like a
record being written to the database.

However, sometimes all you care about for a particular feature is that
it is written to the database. For example, I have an app where users
can send each other messages. I have two separate Scenarios for sending
and receiving. In sending Scenario I verify that there is a db record
with certain attributes. In the receiving Scenario, I start by creating
that same db record, and then I verify what the receiver should see in
the UI.

I hope that helps. I'm not a perfect tester, so I look forward to
someone else's comments!

Paul
Shane M. (Guest)
on 2008-11-24 23:41
(Received via mailing list)
On 25/11/2008, at 8:37 AM, Pau C. wrote:

> record being written to the database.
>

Hi Paul

I agree with you.  The thing is that there is no div tag or id that I
can use to identify it.

I'm not an expert at regexpr .... the output on screen is:

<p>
   <b>Token:</b>
   1f68e325fefd2cd99b91e959a033213e3875bcd5
</p>

So that was why I went with the solution I did.  I guess one option is
adding an id to it for testing .... but then that could be a fragile
approach.

Cheers
Shane
Pau C. (Guest)
on 2008-11-25 04:53
Shane M. wrote:
> I'm not an expert at regexpr .... the output on screen is:

I'm no regex expert, but it is such a useful skill I'm always trying to
improve.

This might do it for you:

/\<p\>\s*\<b\>Token\:\<\/b\>\s*[a-f0-9]{40}\s*\<\/p\>/m

Cheers,
Paul
Pau C. (Guest)
on 2008-11-25 04:56
Pau C. wrote:
> /\<p\>\s*\<b\>Token\:\<\/b\>\s*[a-f0-9]{40}\s*\<\/p\>/m

On second thought, you might want to make that regex more generic. When
you refactor your view code (i.e. insert divs, add ids/classes, and get
rid of the <b> tags--which are evil) then your test won't break.

The customer cares that there is a token, not that the token is in a <p>
tag and the label is bold.

Paul
Mark W. (Guest)
on 2008-11-25 05:35
(Received via mailing list)
On Mon, Nov 24, 2008 at 6:56 PM, Pau C. <removed_email_address@domain.invalid> 
wrote:

> Pau C. wrote:
> > /\<p\>\s*\<b\>Token\:\<\/b\>\s*[a-f0-9]{40}\s*\<\/p\>/m
>
> On second thought, you might want to make that regex more generic. When
> you refactor your view code (i.e. insert divs, add ids/classes, and get
> rid of the <b> tags--which are evil) then your test won't break.
>
> The customer cares that there is a token, not that the token is in a <p>
> tag and the label is bold.
>

Yes, but it's important that the token appear under the Token label. I
think
it might be difficult to specify that in a generic way.

This is why I don't mind doing things like adding ids solely for the
sake of
testing. Testing is good thing to do - there's no shame in making code
changes to make tests better.

///ark
Peter J. (Guest)
on 2008-11-25 05:39
(Received via mailing list)
On Mon, Nov 24, 2008 at 10:35 PM, Mark W. <removed_email_address@domain.invalid> 
wrote:
>> tag and the label is bold.
>
> Yes, but it's important that the token appear under the Token label. I think
> it might be difficult to specify that in a generic way.

I wouldn't use a Regexp to find this.  Look into assert_select, or use
response.should have_tag (which is a wrapper for assert_select) if you
prefer to stay RSpec'y.

Peter
Mark W. (Guest)
on 2008-11-25 05:57
(Received via mailing list)
On Mon, Nov 24, 2008 at 7:39 PM, Peter J.
<removed_email_address@domain.invalid>wrote:

> On Mon, Nov 24, 2008 at 10:35 PM, Mark W. <removed_email_address@domain.invalid> wrote:
> > On Mon, Nov 24, 2008 at 6:56 PM, Pau C. <removed_email_address@domain.invalid> wrote:
> >>
> >> Pau C. wrote:
> >> > /\<p\>\s*\<b\>Token\:\<\/b\>\s*[a-f0-9]{40}\s*\<\/p\>/m
>


> I wouldn't use a Regexp to find this.  Look into assert_select, or use
> response.should have_tag (which is a wrapper for assert_select) if you
> prefer to stay RSpec'y.
>

I don't see how you could use assert_select for this. I think you'd need
an
id somewhere to "anchor" the have_tag. But I'd be willing to learn.

///ark
Andrew P. (Guest)
on 2008-11-25 06:54
(Received via mailing list)
You definitely should have an id for your output. One of the really
good things about feature testing is that it helps you identify what
needs to be seen in your output, and by that I don't mean specific
text, but rather a semantic meaning of your output, in this case a
project containing a token. You should be using css id's and/or
classes to identify these things.

This will help you write less brittle features that don't depend on
the content of something, or even worse the label describing it.

HTH

Andrew


2008/11/24 Shane M. <removed_email_address@domain.invalid>:
Matt W. (Guest)
on 2008-11-25 10:52
(Received via mailing list)
On 25 Nov 2008, at 02:23, Andrew P. wrote:

> You definitely should have an id for your output. One of the really
> good things about feature testing is that it helps you identify what
> needs to be seen in your output, and by that I don't mean specific
> text, but rather a semantic meaning of your output, in this case a
> project containing a token. You should be using css id's and/or
> classes to identify these things.
>
> This will help you write less brittle features that don't depend on
> the content of something, or even worse the label describing it.

+1

The person I often sit down to pair with on features is our CSS /
markup hacker. You can write really nice features if you work to make
them meaningful within the context of the markup (and make the markup
meaningful within the context of the feature).

As well as #assert_select, check out the #within method that webrat
gives you - you can use it to scope queries against the DOM of the
response down to part of the page.

Also I'd suggest looking at using Hpricot for validating the response
- it's used internally by webrat and is a really nice API for walking
the HTML produced by the response.

cheers,
Matt
David C. (Guest)
on 2008-11-25 16:44
(Received via mailing list)
On Tue, Nov 25, 2008 at 2:52 AM, Matt W. <removed_email_address@domain.invalid> 
wrote:
>> This will help you write less brittle features that don't depend on
> you - you can use it to scope queries against the DOM of the response down
> to part of the page.
>
> Also I'd suggest looking at using Hpricot for validating the response - it's
> used internally by webrat and is a really nice API for walking the HTML
> produced by the response.

Actually Webrat now uses nokogiri and ships with two very powerful
matchers: have_xpath and have_selector that might eliminate your need
to open up hpricot or nokogiri directly in the steps.

http://github.com/brynary/webrat/tree/master

Cheers,
David
This topic is locked and can not be replied to.