Hello everyone,
I''m just working my way through the RSpec/Cucumber book, I love the
tool but
not so much the learning curve :(
Starting with my first view, is it okay for me, in the BDD world, to do the
following or can I put them all in one ''it'' block to save on
having to
render the page every time. Or must they be in separate blocks with separate
renders? Or is there a fourth more elegant solution?
%w{ name address_1 address_2 address_3 postcode town_city state country
email phone www }.each do |field|
it "renders form field #{field} to create a new competition" do
@competition.stub!(field.intern).and_return ''''
render "competitions/new.html.erb"
response.should have_selector("input[type=text]", :name =>
"competition[#{field}]", :value => '''')
end
end
Is it okay to post this type of question if nothing jumps out at me after
googling?
Thanks
ants
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100513/50980af4/attachment.html>
On May 13, 2010, at 6:41 AM, Ants Pants wrote:> Hello everyone, > > I''m just working my way through the RSpec/Cucumber book, I love the tool but not so much the learning curve :(Welcome! We''re here to help.> Starting with my first view, is it okay for me, in the BDD world, to do the following or can I put them all in one ''it'' block to save on having to render the page every time. Or must they be in separate blocks with separate renders? Or is there a fourth more elegant solution? > > %w{ name address_1 address_2 address_3 postcode town_city state country email phone www }.each do |field| > it "renders form field #{field} to create a new competition" do > @competition.stub!(field.intern).and_return '''' > render "competitions/new.html.erb" > response.should have_selector("input[type=text]", :name => "competition[#{field}]", :value => '''') > end > end > > Is it okay to post this type of question if nothing jumps out at me after googling?Yes! And thanks for googling first. There is a guideline that comes from TDD that there should be one expectation per example. This is not a law, and is not necessarily the best way to go every time. One benefit is that it''s easier to read the examples and understand what they''re specifying. Another is that when we make a change in the implementation that results in an example failing, if there are multiple expectations that should fail, we learn more if they''re all in separate examples than if they''re all piled up in one example. In terms of iterating through a list of fields, I personally do it all the time and it rarely causes any pain _as long as it is only one level deep_. If you start nesting these, you''re in for a world of pain when new requirements come in that point to a change in behaviour, because you have to start teasing things apart. Another approach to the same issue would be a custom matcher: Rspec::Matchers.define :have_text_field_named do |name| match do |response| response.should have_selector("input[type=text]", :name => "competition[#{name}]", :value => '''') end failure_message_for_should do |response| "expected text field named #{name}, got:\n#{response.body.inspect}" end end Now you can say: describe "competitions/new.html.erb" do describe "form fields" do before(:each) do assigns[:competition] = double(''competition'').as_null_object end %w[name address_1 address_2 address_3 postcode town_city state country email phone www].each do |field| it "renders a #{field} field to create a new competition" do render response.should have_text_field_named(field) end end end end Notes: - using as_null_object means you don''t have to stub out the methods on the competition - if you pass the path to the template file as the first argument to the outermost call to describe(), render() will render it implicitly, so it doesn''t need to be in the example as well. - code in the example is now focused on what is unique to that example - I prefer to use %w[] over %w{} because it creates an array, not a hash or a lambda :) All of this said, there is a general trend away from view specs in light of the Cucumber + (Webrat || Capybara) equation. My personal feeling is that it''s important to know how to use them because they are very useful from time to time. But that''s only one opinion. HTH, David> Thanks > > ants
Thanks for so much information that I will look into.
I was aware of using Cucumber/Webrat for this purpose but I''m doing
things
the long way until it feels unnatural. This way, I''ll be in the
position to
weigh up the pros and cons of a best approach in the future.
For now, I''ll leave the fields in the loop as I''d like to be
able to see the
wood for the trees.
Thanks for the tip between {} and [] as coming form Perl, I just thought
they were the delimiters. Still got a lot to learn on all fronts.
Again, thanks.
-ants
On 13 May 2010 15:18, David Chelimsky <dchelimsky at gmail.com> wrote:
> On May 13, 2010, at 6:41 AM, Ants Pants wrote:
>
> > Hello everyone,
> >
> > I''m just working my way through the RSpec/Cucumber book, I
love the tool
> but not so much the learning curve :(
>
> Welcome! We''re here to help.
>
> > Starting with my first view, is it okay for me, in the BDD world, to
do
> the following or can I put them all in one ''it'' block to
save on having to
> render the page every time. Or must they be in separate blocks with
separate
> renders? Or is there a fourth more elegant solution?
> >
> > %w{ name address_1 address_2 address_3 postcode town_city state
country
> email phone www }.each do |field|
> > it "renders form field #{field} to create a new
competition" do
> > @competition.stub!(field.intern).and_return ''''
> > render "competitions/new.html.erb"
> > response.should have_selector("input[type=text]",
:name =>
> "competition[#{field}]", :value => '''')
> > end
> > end
> >
> > Is it okay to post this type of question if nothing jumps out at me
> after googling?
>
> Yes! And thanks for googling first.
>
> There is a guideline that comes from TDD that there should be one
> expectation per example. This is not a law, and is not necessarily the best
> way to go every time. One benefit is that it''s easier to read the
examples
> and understand what they''re specifying. Another is that when we
make a
> change in the implementation that results in an example failing, if there
> are multiple expectations that should fail, we learn more if
they''re all in
> separate examples than if they''re all piled up in one example.
>
> In terms of iterating through a list of fields, I personally do it all the
> time and it rarely causes any pain _as long as it is only one level deep_.
> If you start nesting these, you''re in for a world of pain when new
> requirements come in that point to a change in behaviour, because you have
> to start teasing things apart.
>
> Another approach to the same issue would be a custom matcher:
>
> Rspec::Matchers.define :have_text_field_named do |name|
> match do |response|
> response.should have_selector("input[type=text]", :name =>
> "competition[#{name}]", :value => '''')
> end
>
> failure_message_for_should do |response|
> "expected text field named #{name},
got:\n#{response.body.inspect}"
> end
> end
>
> Now you can say:
>
> describe "competitions/new.html.erb" do
>
> describe "form fields" do
> before(:each) do
> assigns[:competition] =
double(''competition'').as_null_object
> end
>
> %w[name address_1 address_2 address_3 postcode town_city state country
> email phone www].each do |field|
> it "renders a #{field} field to create a new competition"
do
> render
> response.should have_text_field_named(field)
> end
> end
>
> end
> end
>
> Notes:
>
> - using as_null_object means you don''t have to stub out the
methods on the
> competition
> - if you pass the path to the template file as the first argument to the
> outermost call to describe(), render() will render it implicitly, so it
> doesn''t need to be in the example as well.
> - code in the example is now focused on what is unique to that example
> - I prefer to use %w[] over %w{} because it creates an array, not a hash or
> a lambda :)
>
> All of this said, there is a general trend away from view specs in light of
> the Cucumber + (Webrat || Capybara) equation. My personal feeling is that
> it''s important to know how to use them because they are very
useful from
> time to time. But that''s only one opinion.
>
> HTH,
> David
>
> > Thanks
> >
> > ants
>
>
> _______________________________________________
> 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/20100513/99dcb510/attachment-0001.html>
On May 13, 2010, at 10:10 AM, Ants Pants <antsmailinglist at gmail.com> wrote:> Thanks for so much information that I will look into. > > I was aware of using Cucumber/Webrat for this purpose but I''m doing > things the long way until it feels unnatural. This way, I''ll be in > the position to weigh up the pros and cons of a best approach in the > future. > > For now, I''ll leave the fields in the loop as I''d like to be able to > see the wood for the trees. > > Thanks for the tip between {} and [] as coming form Perl, I just > thought they were the delimiters.They are just delimeters. I''m just talking about style.> Still got a lot to learn on all fronts. > > Again, thanks. > > -ants > > On 13 May 2010 15:18, David Chelimsky <dchelimsky at gmail.com> wrote: > On May 13, 2010, at 6:41 AM, Ants Pants wrote: > > > Hello everyone, > > > > I''m just working my way through the RSpec/Cucumber book, I love > the tool but not so much the learning curve :( > > Welcome! We''re here to help. > > > Starting with my first view, is it okay for me, in the BDD world, > to do the following or can I put them all in one ''it'' block to save > on having to render the page every time. Or must they be in separate > blocks with separate renders? Or is there a fourth more elegant > solution? > > > > %w{ name address_1 address_2 address_3 postcode town_city state > country email phone www }.each do |field| > > it "renders form field #{field} to create a new competition" do > > @competition.stub!(field.intern).and_return '''' > > render "competitions/new.html.erb" > > response.should have_selector("input[type=text]", :name => > "competition[#{field}]", :value => '''') > > end > > end > > > > Is it okay to post this type of question if nothing jumps out at > me after googling? > > Yes! And thanks for googling first. > > There is a guideline that comes from TDD that there should be one > expectation per example. This is not a law, and is not necessarily > the best way to go every time. One benefit is that it''s easier to > read the examples and understand what they''re specifying. Another is > that when we make a change in the implementation that results in an > example failing, if there are multiple expectations that should > fail, we learn more if they''re all in separate examples than if > they''re all piled up in one example. > > In terms of iterating through a list of fields, I personally do it > all the time and it rarely causes any pain _as long as it is only > one level deep_. If you start nesting these, you''re in for a world > of pain when new requirements come in that point to a change in > behaviour, because you have to start teasing things apart. > > Another approach to the same issue would be a custom matcher: > > Rspec::Matchers.define :have_text_field_named do |name| > match do |response| > response.should have_selector("input[type=text]", :name => > "competition[#{name}]", :value => '''') > end > > failure_message_for_should do |response| > "expected text field named #{name}, got:\n#{response.body.inspect}" > end > end > > Now you can say: > > describe "competitions/new.html.erb" do > > describe "form fields" do > before(:each) do > assigns[:competition] = double(''competition'').as_null_object > end > > %w[name address_1 address_2 address_3 postcode town_city state > country email phone www].each do |field| > it "renders a #{field} field to create a new competition" do > render > response.should have_text_field_named(field) > end > end > > end > end > > Notes: > > - using as_null_object means you don''t have to stub out the methods > on the competition > - if you pass the path to the template file as the first argument to > the outermost call to describe(), render() will render it > implicitly, so it doesn''t need to be in the example as well. > - code in the example is now focused on what is unique to that example > - I prefer to use %w[] over %w{} because it creates an array, not a > hash or a lambda :) > > All of this said, there is a general trend away from view specs in > light of the Cucumber + (Webrat || Capybara) equation. My personal > feeling is that it''s important to know how to use them because they > are very useful from time to time. But that''s only one opinion. > > HTH, > David > > > Thanks > > > > ants > > > _______________________________________________ > 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/20100513/00082163/attachment.html>
On 13 May 2010, at 12:41, Ants Pants wrote:> Hello everyone,Hello and welcome :)> I''m just working my way through the RSpec/Cucumber book, I love the tool but not so much the learning curve :( > > Starting with my first view, is it okay for me, in the BDD world, to do the following or can I put them all in one ''it'' block to save on having to render the page every time.Don''t worry about performance here - it''s negligible. In general I always err towards the idea of ''one assertion per test'', so that when I get a failing test (or ''example'' as we call them in RSpec) I know exactly what has gone broken.> Or must they be in separate blocks with separate renders? Or is there a fourth more elegant solution?Some people don''t bother testing views in this much detail, and just rely on Cucumber tests to tell them whether the page works as expected. On the other hand you might well find that this level of detail helps you to think about the design of the objects that the view uses. If you search this list for previous threads about ''should I spec views'' you will find plenty has already been said on this topic.> > %w{ name address_1 address_2 address_3 postcode town_city state country email phone www }.each do |field| > it "renders form field #{field} to create a new competition" do > @competition.stub!(field.intern).and_return '''' > render "competitions/new.html.erb" > response.should have_selector("input[type=text]", :name => "competition[#{field}]", :value => '''') > end > end > > Is it okay to post this type of question if nothing jumps out at me after googling?Of course but remember we''re all busy people and not getting paid for this - remember to ask the plants[1] in the office before you ask us!> > Thanks > > ants > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users[1]http://www.cb1.com/~john/computing/rubber-plant-effect.html