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.
17d2c907d8bff4d5f78da74bc4d38466?d=identicon&s=25 Shane Mingins (smingins)
on 2008-11-24 17: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 Mingins
ELC Technologies (TM)
1921 State Street
Santa Barbara, CA 93101


Phone: +64 4 568 6684
Mobile: +64 21 435 586
Email:  smingins@elctech.com
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
90e140f8553ecdec1b0d7dbf608a0561?d=identicon&s=25 Pau Cor (phylae)
on 2008-11-24 20:37
Shane Mingins 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
17d2c907d8bff4d5f78da74bc4d38466?d=identicon&s=25 Shane Mingins (smingins)
on 2008-11-24 22:41
(Received via mailing list)
On 25/11/2008, at 8:37 AM, Pau Cor 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
90e140f8553ecdec1b0d7dbf608a0561?d=identicon&s=25 Pau Cor (phylae)
on 2008-11-25 03:53
Shane Mingins 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
90e140f8553ecdec1b0d7dbf608a0561?d=identicon&s=25 Pau Cor (phylae)
on 2008-11-25 03:56
Pau Cor 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
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-25 04:35
(Received via mailing list)
On Mon, Nov 24, 2008 at 6:56 PM, Pau Cor <lists@ruby-forum.com> wrote:

> Pau Cor 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
D069ac0170dc6c93bad77734258fadae?d=identicon&s=25 Peter Jaros (Guest)
on 2008-11-25 04:39
(Received via mailing list)
On Mon, Nov 24, 2008 at 10:35 PM, Mark Wilden <mark@mwilden.com> 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
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-25 04:57
(Received via mailing list)
On Mon, Nov 24, 2008 at 7:39 PM, Peter Jaros
<peter.a.jaros@gmail.com>wrote:

> On Mon, Nov 24, 2008 at 10:35 PM, Mark Wilden <mark@mwilden.com> wrote:
> > On Mon, Nov 24, 2008 at 6:56 PM, Pau Cor <lists@ruby-forum.com> wrote:
> >>
> >> Pau Cor 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
85d99e7678d8720f6e00ab0f60fe6ea9?d=identicon&s=25 Andrew Premdas (Guest)
on 2008-11-25 05: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 Mingins <smingins@elctech.com>:
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2008-11-25 09:52
(Received via mailing list)
On 25 Nov 2008, at 02:23, Andrew Premdas 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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-11-25 15:44
(Received via mailing list)
On Tue, Nov 25, 2008 at 2:52 AM, Matt Wynne <matt@mattwynne.net> 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.