Hi All,
Wanted to put this idea forward, see what you think of it. I''m using
Aslaks
lorry feature to illustrate this. See
http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb
.
In particular
within("table > tr:nth-child(#{pos.to_i+1})") do
click_link "Destroy"
and
Then /^I should see the following lorries:$/ do |lorries|
lorries.raw[1..-1].each_with_index do |row, i|
row.each_with_index do |cell, j|
response.should have_selector("table > tr:nth-child(#{i+2}) >
td:nth-child(#{j+1})") { |td|
td.inner_text.should == cell
}
end
end
Now imagine this is a real project, and your designer comes along and
decides that lorries really should be shown in a horizontal scrolling
zoomable javascript widgity thing. Now out go the tables and the scenario
breaks.
However if we use something like
within("#lorries > .lorry:nth-child # not tested this syntax,
hope the meaning is clear
then we have
1) Defined semantic tags that the designer should not touch
2) Not relied on any html elements that a designer might change
3) Created a step that works with the meaning of the UI not its presentation
So what do you think?
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081219/ec6774f3/attachment.html>
On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> wrote:> then we have > > 1) Defined semantic tags that the designer should not touch > 2) Not relied on any html elements that a designer might change > 3) Created a step that works with the meaning of the UI not its presentation > > So what do you think?100% agree. The more semantic your test code is, the less likely it is to break, and the more likely it ought to when it does. If there''s no longer a #lorries element on the page, the step will fail, but that''s a lot like saying that if the lorries aren''t on the page the step will fail. And that''s a good thing. Peter
On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> wrote:> Hi All, > > Wanted to put this idea forward, see what you think of it. I''m using Aslaks > lorry feature to illustrate this. See > http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb. > > In particular > > within("table > tr:nth-child(#{pos.to_i+1})") do > click_link "Destroy" > and > > Then /^I should see the following lorries:$/ do |lorries| > lorries.raw[1..-1].each_with_index do |row, i| > row.each_with_index do |cell, j| > response.should have_selector("table > tr:nth-child(#{i+2}) > > td:nth-child(#{j+1})") { |td| > td.inner_text.should == cell > } > end > end > Now imagine this is a real project, and your designer comes along and > decides that lorries really should be shown in a horizontal scrolling > zoomable javascript widgity thing. Now out go the tables and the scenario > breaks. > > However if we use something like > > within("#lorries > .lorry:nth-child # not tested this syntax, > hope the meaning is clear > > then we have > > 1) Defined semantic tags that the designer should not touch > 2) Not relied on any html elements that a designer might change > 3) Created a step that works with the meaning of the UI not its presentation > > So what do you think? >I agree with your sentiments. It''s how I access (and encourage others to access) the views (both in step definitions and in view specs). -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com
> On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> > wrote: >> Hi All, >> >> Wanted to put this idea forward, see what you think of it. I''m >> using Aslaks >> lorry feature to illustrate this. See >> http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb >> . >> >> In particular >> >> within("table > tr:nth-child(#{pos.to_i+1})") do >> click_link "Destroy" >> and >> >> Then /^I should see the following lorries:$/ do |lorries| >> lorries.raw[1..-1].each_with_index do |row, i| >> row.each_with_index do |cell, j| >> response.should have_selector("table > tr:nth-child(#{i+2}) > >> td:nth-child(#{j+1})") { |td| >> td.inner_text.should == cell >> } >> end >> end >> Now imagine this is a real project, and your designer comes along and >> decides that lorries really should be shown in a horizontal scrolling >> zoomable javascript widgity thing. Now out go the tables and the >> scenario >> breaks. >> >> However if we use something like >> >> within("#lorries > .lorry:nth-child # not tested this >> syntax, >> hope the meaning is clear >> >> then we have >> >> 1) Defined semantic tags that the designer should not touch >> 2) Not relied on any html elements that a designer might change >> 3) Created a step that works with the meaning of the UI not its >> presentation >> >> So what do you think? >> >Feel free to submit a patch. Aslak> I agree with your sentiments. It''s how I access (and encourage others > to access) the views (both in step definitions and in view specs). > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Is this a feature request or a style thing? On Fri, Dec 19, 2008 at 11:01 AM, Aslak Helles?y <aslak.hellesoy at gmail.com> wrote:> >> On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> >> wrote: >>> >>> Hi All, >>> >>> Wanted to put this idea forward, see what you think of it. I''m using >>> Aslaks >>> lorry feature to illustrate this. See >>> >>> http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb. >>> >>> In particular >>> >>> within("table > tr:nth-child(#{pos.to_i+1})") do >>> click_link "Destroy" >>> and >>> >>> Then /^I should see the following lorries:$/ do |lorries| >>> lorries.raw[1..-1].each_with_index do |row, i| >>> row.each_with_index do |cell, j| >>> response.should have_selector("table > tr:nth-child(#{i+2}) > >>> td:nth-child(#{j+1})") { |td| >>> td.inner_text.should == cell >>> } >>> end >>> end >>> Now imagine this is a real project, and your designer comes along and >>> decides that lorries really should be shown in a horizontal scrolling >>> zoomable javascript widgity thing. Now out go the tables and the scenario >>> breaks. >>> >>> However if we use something like >>> >>> within("#lorries > .lorry:nth-child # not tested this syntax, >>> hope the meaning is clear >>> >>> then we have >>> >>> 1) Defined semantic tags that the designer should not touch >>> 2) Not relied on any html elements that a designer might change >>> 3) Created a step that works with the meaning of the UI not its >>> presentation >>> >>> So what do you think? >>> >> > > Feel free to submit a patch. > > Aslak > >> I agree with your sentiments. It''s how I access (and encourage others >> to access) the views (both in step definitions and in view specs). >> >> -- >> Zach Dennis >> http://www.continuousthinking.com >> http://www.mutuallyhuman.com >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Fri, Dec 19, 2008 at 1:13 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> Is this a feature request or a style thing?I believe strictly style. Webrat supports within already, ie: within "#my-css-selector" do |scope| scope.should have_selector("child element") end> > On Fri, Dec 19, 2008 at 11:01 AM, Aslak Helles?y > <aslak.hellesoy at gmail.com> wrote: >> >>> On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> >>> wrote: >>>> >>>> Hi All, >>>> >>>> Wanted to put this idea forward, see what you think of it. I''m using >>>> Aslaks >>>> lorry feature to illustrate this. See >>>> >>>> http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb. >>>> >>>> In particular >>>> >>>> within("table > tr:nth-child(#{pos.to_i+1})") do >>>> click_link "Destroy" >>>> and >>>> >>>> Then /^I should see the following lorries:$/ do |lorries| >>>> lorries.raw[1..-1].each_with_index do |row, i| >>>> row.each_with_index do |cell, j| >>>> response.should have_selector("table > tr:nth-child(#{i+2}) > >>>> td:nth-child(#{j+1})") { |td| >>>> td.inner_text.should == cell >>>> } >>>> end >>>> end >>>> Now imagine this is a real project, and your designer comes along and >>>> decides that lorries really should be shown in a horizontal scrolling >>>> zoomable javascript widgity thing. Now out go the tables and the scenario >>>> breaks. >>>> >>>> However if we use something like >>>> >>>> within("#lorries > .lorry:nth-child # not tested this syntax, >>>> hope the meaning is clear >>>> >>>> then we have >>>> >>>> 1) Defined semantic tags that the designer should not touch >>>> 2) Not relied on any html elements that a designer might change >>>> 3) Created a step that works with the meaning of the UI not its >>>> presentation >>>> >>>> So what do you think? >>>> >>> >> >> Feel free to submit a patch. >> >> Aslak >> >>> I agree with your sentiments. It''s how I access (and encourage others >>> to access) the views (both in step definitions and in view specs). >>> >>> -- >>> Zach Dennis >>> http://www.continuousthinking.com >>> http://www.mutuallyhuman.com >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >-- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com
Was just using your code as an example, not being critical of it. Sorry if it came out that way :). In its context it makes its point very clearly. Andrew 2008/12/19 Aslak Helles?y <aslak.hellesoy at gmail.com>> > On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> >> wrote: >> >>> Hi All, >>> >>> Wanted to put this idea forward, see what you think of it. I''m using >>> Aslaks >>> lorry feature to illustrate this. See >>> >>> http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb >>> . >>> >>> In particular >>> >>> within("table > tr:nth-child(#{pos.to_i+1})") do >>> click_link "Destroy" >>> and >>> >>> Then /^I should see the following lorries:$/ do |lorries| >>> lorries.raw[1..-1].each_with_index do |row, i| >>> row.each_with_index do |cell, j| >>> response.should have_selector("table > tr:nth-child(#{i+2}) > >>> td:nth-child(#{j+1})") { |td| >>> td.inner_text.should == cell >>> } >>> end >>> end >>> Now imagine this is a real project, and your designer comes along and >>> decides that lorries really should be shown in a horizontal scrolling >>> zoomable javascript widgity thing. Now out go the tables and the scenario >>> breaks. >>> >>> However if we use something like >>> >>> within("#lorries > .lorry:nth-child # not tested this syntax, >>> hope the meaning is clear >>> >>> then we have >>> >>> 1) Defined semantic tags that the designer should not touch >>> 2) Not relied on any html elements that a designer might change >>> 3) Created a step that works with the meaning of the UI not its >>> presentation >>> >>> So what do you think? >>> >>> >> > Feel free to submit a patch. > > Aslak > > > I agree with your sentiments. It''s how I access (and encourage others >> to access) the views (both in step definitions and in view specs). >> >> -- >> Zach Dennis >> http://www.continuousthinking.com >> http://www.mutuallyhuman.com >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > 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/20081219/ea1e7650/attachment.html>
A style thing, just exploring interactions between features and UI 2008/12/19 David Chelimsky <dchelimsky at gmail.com>> Is this a feature request or a style thing? > > On Fri, Dec 19, 2008 at 11:01 AM, Aslak Helles?y > <aslak.hellesoy at gmail.com> wrote: > > > >> On Fri, Dec 19, 2008 at 1:09 AM, Andrew Premdas <apremdas at gmail.com> > >> wrote: > >>> > >>> Hi All, > >>> > >>> Wanted to put this idea forward, see what you think of it. I''m using > >>> Aslaks > >>> lorry feature to illustrate this. See > >>> > >>> > http://github.com/aslakhellesoy/cucumber_rails/tree/master/features/step_definitions/lorry_steps.rb > . > >>> > >>> In particular > >>> > >>> within("table > tr:nth-child(#{pos.to_i+1})") do > >>> click_link "Destroy" > >>> and > >>> > >>> Then /^I should see the following lorries:$/ do |lorries| > >>> lorries.raw[1..-1].each_with_index do |row, i| > >>> row.each_with_index do |cell, j| > >>> response.should have_selector("table > tr:nth-child(#{i+2}) > > >>> td:nth-child(#{j+1})") { |td| > >>> td.inner_text.should == cell > >>> } > >>> end > >>> end > >>> Now imagine this is a real project, and your designer comes along and > >>> decides that lorries really should be shown in a horizontal scrolling > >>> zoomable javascript widgity thing. Now out go the tables and the > scenario > >>> breaks. > >>> > >>> However if we use something like > >>> > >>> within("#lorries > .lorry:nth-child # not tested this > syntax, > >>> hope the meaning is clear > >>> > >>> then we have > >>> > >>> 1) Defined semantic tags that the designer should not touch > >>> 2) Not relied on any html elements that a designer might change > >>> 3) Created a step that works with the meaning of the UI not its > >>> presentation > >>> > >>> So what do you think? > >>> > >> > > > > Feel free to submit a patch. > > > > Aslak > > > >> I agree with your sentiments. It''s how I access (and encourage others > >> to access) the views (both in step definitions and in view specs). > >> > >> -- > >> Zach Dennis > >> http://www.continuousthinking.com > >> http://www.mutuallyhuman.com > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > 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/20081219/a5bf22e8/attachment.html>