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 at 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
--------------------------------------------------------------------
Privacy and Confidentiality Notice:
The information contained in this electronic mail message is intended
for the named recipient(s) only. It may contain privileged and
confidential information. If you are not an intended recipient, you
must not copy, forward, distribute or take any action in reliance on
it. If you have received this electronic mail message in
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081124/7dbd35d9/attachment.bin>
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 > endThis 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 -- Posted via http://www.ruby-forum.com/.
On 25/11/2008, at 8:37 AM, Pau Cor wrote:> > 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. >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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2423 bytes Desc: not available URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081125/ed441075/attachment.bin>
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 at elctech.com>:> > On 25/11/2008, at 8:37 AM, Pau Cor wrote: > >> >> 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. >> > > 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 > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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 -- Posted via http://www.ruby-forum.com/.
Pau Cor wrote:> /\<p\>\s*\<b\>Token\:\<\/b\>\s*[a-f0-9]{40}\s*\<\/p\>/mOn 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 -- Posted via http://www.ruby-forum.com/.
On Mon, Nov 24, 2008 at 6:56 PM, Pau Cor <lists at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081124/acb42932/attachment-0001.html>
On Mon, Nov 24, 2008 at 10:35 PM, Mark Wilden <mark at mwilden.com> wrote:> On Mon, Nov 24, 2008 at 6:56 PM, Pau Cor <lists at 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.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
On Mon, Nov 24, 2008 at 7:39 PM, Peter Jaros <peter.a.jaros at gmail.com>wrote:> On Mon, Nov 24, 2008 at 10:35 PM, Mark Wilden <mark at mwilden.com> wrote: > > On Mon, Nov 24, 2008 at 6:56 PM, Pau Cor <lists at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081124/b252bf6c/attachment.html>
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
On Tue, Nov 25, 2008 at 2:52 AM, Matt Wynne <matt at mattwynne.net> wrote:> > 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.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> > cheers, > Matt > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >