On Thu, Apr 2, 2009 at 3:55 PM, Matt Wynne <m...@mattwynne.net> wrote:
>
> On 2 Apr 2009, at 02:25, Brandon Olivares wrote:
>
>> Hi,
>>
>> I'm trying to write my first custom matcher.
>>
>> Here's a bit of my example group.
>>
>> describe "/contact/index" do
>> include FormMatchers
>>
>> before(:each) do
>> render 'contact/index'
>> end
>>
>> it "should show the contact form" do
>> response.should have_a_contact_form
>> end
>>
>> describe "the contact form" do
>> context "before it has been submitted" do
>> it "should have a subject dropdown box" do
>> response.should have_a_contact_form do |form|
>> form.should have_a_subject_field
>> end
>> end # it "should have a subject dropdown box"
>>
>> # This should be failing
>> it "should have a name field" do
>> response.should have_a_contact_form do |form|
>> form.should have_a_name_field
>> end
>> end # it "should have a name field"
>>
>> describe "the subject dropdown box" do
>> it "should have a feedback option" do
>> response.should have_a_contact_form do |form|
>> form.should have_a_subject_field do |subject|
>> subject.should have_selector('option', :content => 'Feedback')
>> end
>> end
>> end # it "should have a feedback option"
>>
>> # Etc...
>>
>> end # describe "the subject dropdown box"
>>
>> end # context "before the form has been submitted"
>>
>> end # Describe "the contact form"
>>
>> end # describe "/contact/index"
>>
>> Right now, everything before the describe "the subject dropdown box" is
>> passing, even though the one testing the name field should not because
>> I've
>> not added that field yet.
>>
>> When it gets to the describe block for the subject, I get:
>>
>> NoMethodError in '/contact/index the contact form before it has been
>> submitted the subject dropdown box should have a blank option'
>> undefined method `have_selector' for
>> #<FormMatchers::HaveAFormWithID:0x7f3260ac>
>
> #have_selector is part of webrat. Have you required the appropriate files so
> that method is visible to your new matcher class?
>
>> The have_a_contact_form method is as follows:
>>
>> def have_a_contact_form &block
>> have_a_form_with_id 'contact', &block
>> end
>>
>> That calls a have_a_form_with_id method, which calls the haveAFormWithID
>> class.
>>
>> module FormMatchers
>>
>> class HaveAFormWithID
>>
>> def initialize id, &block
>> @id = id
>> @block = block
>> end
>>
>> def matches? response
>> response.should have_selector('form#%s' % [...@id]) do |form|
>> !...@block or @block.call form
>> end
>> end
>>
>> def description
>> "have a form with id #...@id}"
>> end
>>
>> def failure_message
>> "expected to have a form with ID #...@id}"
>> end
>>
>> def negative_failure_message
>> "expected not to have a form with ID #...@id}"
>> end
>>
>> end
>>
>> def have_a_form_with_id id, &block
>> HaveAFormWithID.new id, &block
>> end
>>
>> end
>>
>> Sorry for all the code. Again this is my first custom matcher, so I could
>> be
>> doing something very wrong.
>>
>> Any help much appreciated.
>>
>> Thanks,
>> Brandon
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> As a P.S. I hate to take the wind out of your sails here, but I was
> reflecting only today how, after 9 months of using RSpec to TDD our Rails
> app, we have massaged the view specs down to almost nothing. IMO 99% of the
> time you should be writing a Cucumber feature instead and leaving it at
> that.
>
To share, one project I'm on has had scenarios provided by the
customer and it is an app with a lot of business rules and the system
contains many components (not a typical Rails CRUD app). The scenarios
themselves focus on high level behaviour. We've used view specs to
drive out the views, and we've only placed the minimal code in the
steps to use the system to prove out the behaviour. Relying solely on
scenarios and step definitions did not work well for the short time it
was tried.
On another project that is entirely different the scenarios themselves
actually fleshed out the requirements of the UI. But the type of app
is vastly different than the first and it just made sense.
While I don't agree that 99% is a rule of thumb I can see where
different apps have different needs, and some will naturally drive out
more of the UI from the scenarios, whereas others will have details to
the UI which may not be the driving force of the feature and its
scenarios, but they need to exist.
I know that style comes into play at some point to. There are some
folks who are cool with putting all view stuff in step definitions and
there are folks who prefer to have minimally sized step definitions
with the details in specs. I can't say who's right or wrong, but I
know where my comfort level is.
Matt, can you say where you gauge your app?
- Are there many little scenarios covering the details of the page?
- Are the scenarios comprised of many steps which look at all aspects
of the page?
- Are the step definitions detail oriented? e.g.: looking at the
project looks at all of the pieces of information it should be
displaying
I'm really interested in this topic as I think I've seen when Cucumber
is relied on too much and I've definitely seen where it's been relied
on too little. So naturally I'm interested to find out more about
people's projects to help gauge where things fall on the continuum,
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
