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
Defined semantic tags that the designer should not touch
Not relied on any html elements that a designer might change
Created a step that works with the meaning of the UI not its
presentation
Defined semantic tags that the designer should not touch
Not relied on any html elements that a designer might change
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.
I believe strictly style. Webrat supports within already, ie:
within “#my-css-selector” do |scope|
scope.should have_selector(“child element”)
end
lorry feature to illustrate this. See
lorries.raw[1…-1].each_with_index do |row, i|
breaks.
3) Created a step that works with the meaning of the UI not its
I agree with your sentiments. It’s how I access (and encourage others