rspec users - Oct 2009 - [BDD] View specs and cucumber -- duplication of effort?

Hi Guys

I''m going to put the cat amongst the pigeons here in the hope of some
clarity falling out of the sky on me.
My question is this: In a world with Cucumber what is the value of
view specs?

In the community (railscamp, for example) there are a fair number of
people using Cucumber and skipping view specs, but still speccing
controllers, models, tricky view helpers and so on.

Why? Because they don''t find them helpful. Indeed they are seen as a
waste of time (money) not only duplicating Cucumber coverage, but also
introducing a high-maintenance example group which designers (who
don''t run tests) will frequently break.

These people aren''t stupid. They''re producing working apps. I
don''t
claim that their work cycle is perfect: this is about utility and
efficiency, or about being lazy or avoiding boredom, if you prefer.

I''ve been working in a mixed environment, with an existing project
which uses rspec and cucumber (sans view specs) and my own green field
app for a different client.
I''ve been following the BDD approach prescribed by the RSpec book (or
so I think). This works, and has produced a lot of LOC.

I''ve not worried, as it has given me plenty of practice with the
various arms of rspec, webrat, and other tools.
Now that I''m more comfortable with them things are starting to get
tiresome, especially duplication, and I''m worried I''m creating
a
monolith. Too many specs => TLDR ?

What should I try using view specs for? Why are they better than
cucumber for this?

"Driving views through examples helps us think about what the view
needs in order for it to do its job. It encourages us to write the
code we wish we had to fulfil those needs."

I''m not sure how this is any different to what I do in the outer
circle with Cucumber. If I write an explicit scenario like
http://gist.github.com/221004 then I already know what the view needs
to let me do.

If I write something more broad-brush (which you will do, if quickly
sketching out features during a design meeting) like "When I add a
page link" I have to then define that step so it goes red (or, heaven
forbid, green). But to write that step definition I have to know how I
can interact with the page. This example actually comes from a broad-
brush step being expanded in the scenario itself rather than hiding it
away in a step definition, but that''s a different subject.

I''m specifying the page''s behaviour in the scenario, or in the
step
definition. Why duplicate this process with a view spec?

I keep coming back to the introduction of chapter 23 in the RSpec book
but don''t seem to be getting anywhere from it.

For the time being I''m going to keep writing view specs, but try to
make them lighter and cut some of the dead wood by describing unusual
or interesting behaviour rather than all behaviour.

I''d love to hear your thoughts.

Regards

Nick

On Wed, Oct 28, 2009 at 9:46 PM, nruth <nick.rutherford at gmail.com>
wrote:
>
> For the time being I''m going to keep writing view specs, but try
to
> make them lighter and cut some of the dead wood by describing unusual
> or interesting behaviour rather than all behaviour.
What a strange rant.  "What''s the value of this? Look at all the
people succeeding without it. This makes no sense to me! ...I''ll keep
doing it."

This is not a church. You will not be excommunicated from BDD. If a
practice doesn''t make sense to you, don''t do it. If *not*
doing it
leads to perceptible hassles and suddenly the reasons for it make
sense, start doing it again.

I don''t write view specs. Other people do. I share your opinion that
Cucumber covers the same ground. Others point out that isolating the
views makes specific interface bugs easier to spot and separate from
controller or model failures.

The argument in favor of view specs makes sense. Your argument against
it makes sense too.  What I can''t understand from your post is what
your persuasive purpose is. I''m not sure if you''re trying to
persuade
_others_ that it''s okay not to write view specs, or persuade
_yourself._



-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

nruth wrote:
> Hi Guys
>
> I''m going to put the cat amongst the pigeons here in the hope of
some
> clarity falling out of the sky on me.
> My question is this: In a world with Cucumber what is the value of
> view specs?
>
> In the community (railscamp, for example) there are a fair number of
> people using Cucumber and skipping view specs, but still speccing
> controllers, models, tricky view helpers and so on.
>
> Why? Because they don''t find them helpful. Indeed they are seen as
a
> waste of time (money) not only duplicating Cucumber coverage, but also
> introducing a high-maintenance example group which designers (who
> don''t run tests) will frequently break.
>
> These people aren''t stupid. They''re producing working
apps. I don''t
> claim that their work cycle is perfect: this is about utility and
> efficiency, or about being lazy or avoiding boredom, if you prefer.
>
> I''ve been working in a mixed environment, with an existing project
> which uses rspec and cucumber (sans view specs) and my own green field
> app for a different client.
> I''ve been following the BDD approach prescribed by the RSpec book
(or
> so I think). This works, and has produced a lot of LOC.
>
> I''ve not worried, as it has given me plenty of practice with the
> various arms of rspec, webrat, and other tools.
> Now that I''m more comfortable with them things are starting to get
> tiresome, especially duplication, and I''m worried I''m
creating a
> monolith. Too many specs => TLDR ?
>
> What should I try using view specs for? Why are they better than
> cucumber for this?
>
> "Driving views through examples helps us think about what the view
> needs in order for it to do its job. It encourages us to write the
> code we wish we had to fulfil those needs."
>
> I''m not sure how this is any different to what I do in the outer
> circle with Cucumber. If I write an explicit scenario like
> http://gist.github.com/221004 then I already know what the view needs
> to let me do.
>
> If I write something more broad-brush (which you will do, if quickly
> sketching out features during a design meeting) like "When I add a
> page link" I have to then define that step so it goes red (or, heaven
> forbid, green). But to write that step definition I have to know how I
> can interact with the page. This example actually comes from a broad-
> brush step being expanded in the scenario itself rather than hiding it
> away in a step definition, but that''s a different subject.
>
> I''m specifying the page''s behaviour in the scenario, or
in the step
> definition. Why duplicate this process with a view spec?
>
> I keep coming back to the introduction of chapter 23 in the RSpec book
> but don''t seem to be getting anywhere from it.
>
> For the time being I''m going to keep writing view specs, but try
to
> make them lighter and cut some of the dead wood by describing unusual
> or interesting behaviour rather than all behaviour.
>
> I''d love to hear your thoughts.
>
> Regards
>
> Nick
>   

Hi Nick,
View specs can be useful but they can also be very brittle and add undue 
maintenance to a project.  The brittleness, which causes a lot of 
maintenance headaches, usually is caused by specing the design and 
structure too closely.  If the designer changes the layout this 
shouldn''t break the view specs IMO.  I think a good strategy is to
avoid
this is by keeping things very general (as much as you can).  For 
example, you should only verify if the correct text was displayed 
instead of focusing on the HTML structure.  Verifying that certain 
elements are present via their ids but not tag type or css class which 
are subject to change by the designer will also help reduce brittleness.

I''m also of the opinion that view specs *only* make sense on large 
complicated views.  An example of such a page would be a users profile 
page on a social network site.  A lot of stuff is generally displayed on 
a page like that.  Setting up all the data required to test that via 
Cucumber can be very expensive/slow and cucumbersome.  (Especially 
considering that such a page will contain random data and be 
personalized to the person viewing the profile.)  Being able to isolate 
all of that complexity and test it individually with view specs (and 
probably with a Presenter and corresponding spec) will make your life a 
lot easier and actually save you time and from maintenance headaches.  
For simple pages that are already being exercised via Cucumber view 
specs are overkill IMO.  A simple form submission and checking the 
presence of some basic text is well within the bounds of what Cucumber 
should be testing.  If you are finding you want to write "Then I should 
see.. And I should see.. And I should see., etc" that is an indication 
that a view spec *may* be helpful in that situation.

HTH,
Ben

On Oct 28, 2009, at 10:19 PM, Ben Mabey wrote:
> nruth wrote:
>> Hi Guys
>>
>> I''m going to put the cat amongst the pigeons here in the hope
of some
>> clarity falling out of the sky on me.
>> My question is this: In a world with Cucumber what is the value of
>> view specs?
>>
>> In the community (railscamp, for example) there are a fair number of
>> people using Cucumber and skipping view specs, but still speccing
>> controllers, models, tricky view helpers and so on.
>>
>> Why? Because they don''t find them helpful. Indeed they are
seen as a
>> waste of time (money) not only duplicating Cucumber coverage, but  
>> also
>> introducing a high-maintenance example group which designers (who
>> don''t run tests) will frequently break.
>>
>> These people aren''t stupid. They''re producing working
apps. I don''t
>> claim that their work cycle is perfect: this is about utility and
>> efficiency, or about being lazy or avoiding boredom, if you prefer.
>>
>> I''ve been working in a mixed environment, with an existing
project
>> which uses rspec and cucumber (sans view specs) and my own green  
>> field
>> app for a different client.
>> I''ve been following the BDD approach prescribed by the RSpec
book (or
>> so I think). This works, and has produced a lot of LOC.
>>
>> I''ve not worried, as it has given me plenty of practice with
the
>> various arms of rspec, webrat, and other tools.
>> Now that I''m more comfortable with them things are starting to
get
>> tiresome, especially duplication, and I''m worried I''m
creating a
>> monolith. Too many specs => TLDR ?
>>
>> What should I try using view specs for? Why are they better than
>> cucumber for this?
>>
>> "Driving views through examples helps us think about what the view
>> needs in order for it to do its job. It encourages us to write the
>> code we wish we had to fulfil those needs."
>>
>> I''m not sure how this is any different to what I do in the
outer
>> circle with Cucumber. If I write an explicit scenario like
>> http://gist.github.com/221004 then I already know what the view needs
>> to let me do.
>>
>> If I write something more broad-brush (which you will do, if quickly
>> sketching out features during a design meeting) like "When I add a
>> page link" I have to then define that step so it goes red (or,
heaven
>> forbid, green). But to write that step definition I have to know  
>> how I
>> can interact with the page. This example actually comes from a broad-
>> brush step being expanded in the scenario itself rather than hiding  
>> it
>> away in a step definition, but that''s a different subject.
>>
>> I''m specifying the page''s behaviour in the scenario,
or in the step
>> definition. Why duplicate this process with a view spec?
>>
>> I keep coming back to the introduction of chapter 23 in the RSpec  
>> book
>> but don''t seem to be getting anywhere from it.
>>
>> For the time being I''m going to keep writing view specs, but
try to
>> make them lighter and cut some of the dead wood by describing unusual
>> or interesting behaviour rather than all behaviour.
>>
>> I''d love to hear your thoughts.
>>
>> Regards
>>
>> Nick
>>
>
>
> Hi Nick,
> View specs can be useful but they can also be very brittle and add  
> undue maintenance to a project.  The brittleness, which causes a lot  
> of maintenance headaches, usually is caused by specing the design  
> and structure too closely.  If the designer changes the layout this  
> shouldn''t break the view specs IMO.  I think a good strategy is to
> avoid this is by keeping things very general (as much as you can).   
> For example, you should only verify if the correct text was  
> displayed instead of focusing on the HTML structure.  Verifying that  
> certain elements are present via their ids but not tag type or css  
> class which are subject to change by the designer will also help  
> reduce brittleness.
>
> I''m also of the opinion that view specs *only* make sense on large
> complicated views.  An example of such a page would be a users  
> profile page on a social network site.  A lot of stuff is generally  
> displayed on a page like that.  Setting up all the data required to  
> test that via Cucumber can be very expensive/slow and cucumbersome.   
> (Especially considering that such a page will contain random data  
> and be personalized to the person viewing the profile.)  Being able  
> to isolate all of that complexity and test it individually with view  
> specs (and probably with a Presenter and corresponding spec) will  
> make your life a lot easier and actually save you time and from  
> maintenance headaches.  For simple pages that are already being  
> exercised via Cucumber view specs are overkill IMO.  A simple form  
> submission and checking the presence of some basic text is well  
> within the bounds of what Cucumber should be testing.  If you are  
> finding you want to write "Then I should see.. And I should see..  
> And I should see., etc" that is an indication that a view spec *may*  
> be helpful in that situation.
>
> HTH,
> Ben

One thing we''re missing in this conversation is the notion of team  
structure and how it impacts these decisions. In my past experience  
with tools like FitNesse (which plays in the same space as Cucumber as  
a customer-facing, documentation-focused, collaboration tool), I  
worked with situations in which a separate QA team + BAs owned the  
FitNesse tests. If I were working on a team like that now, with a QA  
team owning the Cucumber scenarios and a separate group of developers  
owning the RSpec examples, I''d lean more towards view specs. If
I''m on
a project in which developers own scenarios and code examples, then  
I''d lean away from them. In either case, the leaning is a matter of  
balance.

Also keep in mind that this is about _process_, not just about the end  
result. We want to be able to progress in small, verifiable steps.  
That means really short cycles of red/green/refactor. If the structure  
of a given page in an app is simple enough that you can get pretty  
quickly from red to green just using Cucumber, then maybe that page  
doesn''t need view specs. That''s one extreme. If you find that
you''re
spending an hour chasing ghosts in the red, then that''s the other  
extreme, and view specs are in order. Everything in between falls  
along a spectrum, and it''s up to you to find the sweet spot, which  
_will_ vary from team to team, project to project, and even view to  
view.

HTH,
David

On Thu, Oct 29, 2009 at 10:19 AM, David Chelimsky <dchelimsky at
gmail.com> wrote:
>
> Everything in between falls along a spectrum, and it''s up to you
to find the
> sweet spot, which _will_ vary from team to team, project to project, and
> even view to view.
Here''s a discussion on another forum in which nearly the exact same
question was asked:
http://stackoverflow.com/questions/1563007/

An excerpt from my answer:

* * * * *
As a heuristic, I''d suggest that you should _strongly_ consider
writing a unit test any time any of the following questions can be
answered "Yes":

* Is the code I''m writing more than trivially complicated?
* Does this code exist primarily to give answers to other code?
* Is this existing code that I''m refactoring (that doesn''t
already
have a unit test)?
* Have I found a bug in this code? (If so, write a unit test before
fixing it so it never sneaks in again.)
* Do I have to think for more than ten seconds about the most elegant
way to implement this code?
* Is my Spidey Sense tingling?

If none of the above is true, then _maybe_ you can get away with just
doing integration testing. Again, there are a lot of cases where
that''s reasonable. But if you do run into problems later, be prepared
to pay the price -- and that price should include writing unit tests
at any moment if they seem called for.
* * * * *

-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Oct 29, 2009, at 10:09 AM, Stephen Eley <sfeley at gmail.com> wrote:
> On Thu, Oct 29, 2009 at 10:19 AM, David Chelimsky <dchelimsky at
gmail.com
> > wrote:
>>
>> Everything in between falls along a spectrum, and it''s up to
you to
>> find the
>> sweet spot, which _will_ vary from team to team, project to  
>> project, and
>> even view to view.
>
> Here''s a discussion on another forum in which nearly the exact
same
> question was asked:
> http://stackoverflow.com/questions/1563007/
>
> An excerpt from my answer:
>
> * * * * *
> As a heuristic, I''d suggest that you should _strongly_ consider
> writing a unit test any time any of the following questions can be
> answered "Yes":
>
> * Is the code I''m writing more than trivially complicated?
> * Does this code exist primarily to give answers to other code?
> * Is this existing code that I''m refactoring (that
doesn''t already
> have a unit test)?
> * Have I found a bug in this code? (If so, write a unit test before
> fixing it so it never sneaks in again.)
> * Do I have to think for more than ten seconds about the most elegant
> way to implement this code?
> * Is my Spidey Sense tingling?
>
> If none of the above is true, then _maybe_ you can get away with just
> doing integration testing. Again, there are a lot of cases where
> that''s reasonable. But if you do run into problems later, be
prepared
> to pay the price -- and that price should include writing unit tests
> at any moment if they seem called for.
Now _that_ sounds like the voice of reason!

David

> * * * * *
>
> -- 
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Steve, I''m trying to persuade myself, or rather be persuaded by
someone who knows better.

Since writing this I got an update of the RSpec book and noted that
chapter 23 has been rewritten to discuss this. That''s great, as the
version I had really didn''t cover it at all. Thumbs up to David et al
for writing on it.

Also thanks all for the replies, they to some extent reinforce what I
was thinking myself, about complexity of said views, but also a lot of
new insight too!

On Oct 29, 3:09?pm, Stephen Eley <sfe... at gmail.com>
wrote:
> On Thu, Oct 29, 2009 at 10:19 AM, David Chelimsky <dchelim... at
gmail.com> wrote:
>
> > Everything in between falls along a spectrum, and it''s up to
you to find the
> > sweet spot, which _will_ vary from team to team, project to project,
and
> > even view to view.
>
> Here''s a discussion on another forum in which nearly the exact
same
> question was asked:http://stackoverflow.com/questions/1563007/
>
> An excerpt from my answer:
>
> * * * * *
> As a heuristic, I''d suggest that you should _strongly_ consider
> writing a unit test any time any of the following questions can be
> answered "Yes":
>
> * Is the code I''m writing more than trivially complicated?
> * Does this code exist primarily to give answers to other code?
> * Is this existing code that I''m refactoring (that
doesn''t already
> have a unit test)?
> * Have I found a bug in this code? (If so, write a unit test before
> fixing it so it never sneaks in again.)
> * Do I have to think for more than ten seconds about the most elegant
> way to implement this code?
> * Is my Spidey Sense tingling?
>
> If none of the above is true, then _maybe_ you can get away with just
> doing integration testing. Again, there are a lot of cases where
> that''s reasonable. But if you do run into problems later, be
prepared
> to pay the price -- and that price should include writing unit tests
> at any moment if they seem called for.
> * * * * *
>
> --
> Have Fun,
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On Wed, Oct 28, 2009 at 20:46, nruth <nick.rutherford at gmail.com> wrote:
> I''m going to put the cat amongst the pigeons here in the hope of
some
> clarity falling out of the sky on me.
> My question is this: In a world with Cucumber what is the value of
> view specs?
http://blog.thecodewhisperer.com/post/207813060/two-kinds-of-views

Not a Rails-specific nor RSpec-specific answer, but I think it relates
to the question.
-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile
2010: Learn. Practice. Explore.

2009/10/29 nruth <nick.rutherford at gmail.com>
> Hi Guys
>
> I''m going to put the cat amongst the pigeons here in the hope of
some
> clarity falling out of the sky on me.
> My question is this: In a world with Cucumber what is the value of
> view specs?
>
> In the community (railscamp, for example) there are a fair number of
> people using Cucumber and skipping view specs, but still speccing
> controllers, models, tricky view helpers and so on.
>
> Why? Because they don''t find them helpful. Indeed they are seen as
a
> waste of time (money) not only duplicating Cucumber coverage, but also
> introducing a high-maintenance example group which designers (who
> don''t run tests) will frequently break.
>
> These people aren''t stupid. They''re producing working
apps. I don''t
> claim that their work cycle is perfect: this is about utility and
> efficiency, or about being lazy or avoiding boredom, if you prefer.
>
> I''ve been working in a mixed environment, with an existing project
> which uses rspec and cucumber (sans view specs) and my own green field
> app for a different client.
> I''ve been following the BDD approach prescribed by the RSpec book
(or
> so I think). This works, and has produced a lot of LOC.
>
> I''ve not worried, as it has given me plenty of practice with the
> various arms of rspec, webrat, and other tools.
> Now that I''m more comfortable with them things are starting to get
> tiresome, especially duplication, and I''m worried I''m
creating a
> monolith. Too many specs => TLDR ?
>
> What should I try using view specs for? Why are they better than
> cucumber for this?
>
> "Driving views through examples helps us think about what the view
> needs in order for it to do its job. It encourages us to write the
> code we wish we had to fulfil those needs."
>
> I''m not sure how this is any different to what I do in the outer
> circle with Cucumber. If I write an explicit scenario like
> http://gist.github.com/221004 then I already know what the view needs
> to let me do.
>
> If I write something more broad-brush (which you will do, if quickly
> sketching out features during a design meeting) like "When I add a
> page link" I have to then define that step so it goes red (or, heaven
> forbid, green). But to write that step definition I have to know how I
> can interact with the page. This example actually comes from a broad-
> brush step being expanded in the scenario itself rather than hiding it
> away in a step definition, but that''s a different subject.
>
> I''m specifying the page''s behaviour in the scenario, or
in the step
> definition. Why duplicate this process with a view spec?
>
> I keep coming back to the introduction of chapter 23 in the RSpec book
> but don''t seem to be getting anywhere from it.
>
> For the time being I''m going to keep writing view specs, but try
to
> make them lighter and cut some of the dead wood by describing unusual
> or interesting behaviour rather than all behaviour.
>
> I''d love to hear your thoughts.
>
> Regards
>
> Nick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Currently I don''t do view specs, but I''m beginning to see a
use for them.
This is all to do with a recent change change in my thinking about features.
In addition to all the other things features do, I am now seeing them as a
map to what the "business" wants from the application. This map works
best
if it is clear and simple (a bit like the London tube map). Putting lots of
view details in the features (and I should see a wibble field etc. ...)
pollutes this map with clutter that is not relevant to the "business"
context. So view specs seem like a really good place to spec all this
detail.

Another benefit of this is that the view specs might end up as another map
that is useful to designers and front end developers.

I''ve been thinking about features, specs and even code as maps
recently. It
provides a really good explanation of why names and description are so
important.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20091104/566e2f14/attachment.html>

On Wed, Nov 4, 2009 at 10:56 AM, Andrew Premdas <apremdas at gmail.com>
wrote:
>
> Putting lots of
> view details in the features (and I should see a wibble field etc. ...)
> pollutes this map with clutter that is not relevant to the
"business"
> context. So view specs seem like a really good place to spec all this
> detail.
I think this is a really good point.  However, I''d suggest that this
could still be done in Cucumber.  If you have a step like "Then I
should see my wozbat''s details" you could put your detail map in
the
step definition:

Then /^I should see my wozbat''s details$/ do
  Then "I should see my wozbat''s wibble"
  Then "I should see my wozbat''s wobble"
  Then "I should see my wozbat''s wombat"
end

And so forth.  Generalize or specialize as needed.

I don''t think this is conceptually better than doing it in a view
spec.  View specs probably are philosophically superior in most cases.
 The advantage is that in Cucumber this takes essentially no extra
setup and is fairly concise to read, whereas mocking your model
instances in a view spec is a pain and the specs themselves tend to be
much more verbose.


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

2009/11/4 Stephen Eley <sfeley at gmail.com>
> On Wed, Nov 4, 2009 at 10:56 AM, Andrew Premdas <apremdas at
gmail.com>
> wrote:
> >
> > Putting lots of
> > view details in the features (and I should see a wibble field etc.
...)
> > pollutes this map with clutter that is not relevant to the
"business"
> > context. So view specs seem like a really good place to spec all this
> > detail.
>
> I think this is a really good point.  However, I''d suggest that
this
> could still be done in Cucumber.  If you have a step like "Then I
> should see my wozbat''s details" you could put your detail map
in the
> step definition:
>
> Then /^I should see my wozbat''s details$/ do
>  Then "I should see my wozbat''s wibble"
>  Then "I should see my wozbat''s wobble"
>  Then "I should see my wozbat''s wombat"
> end
>
> And so forth.  Generalize or specialize as needed.
>
> I don''t think this is conceptually better than doing it in a view
> spec.  View specs probably are philosophically superior in most cases.
>  The advantage is that in Cucumber this takes essentially no extra
> setup and is fairly concise to read, whereas mocking your model
> instances in a view spec is a pain and the specs themselves tend to be
> much more verbose.
>
>
> --
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Yes you can use step definitions to do this, but I would avoid nesting the
steps and actually make the direct calls e.g.

   response.should_have (#wozbat)

Personally I now think nested steps are evil - but thats another story :)

If the items are fields in forms I''d just assume their presence and
fill
them in in a step e.g.

   when /^I fill in foo form correctly$/ do
      fill_in foo.wibble, :with => "wibbling"

However before I can do this I''m thinking that a view spec that says
the
form has a wibble field would be useful, concise and expressive. The feature
drives what you do with the view, and the view spec specifies whats in the
view. This matches the loop within loop workflow in the rspec book.

Having said all this I haven''t actually done this in practice yet,
going to
try it on my next view.

By the way its nice to find a fellow soul who appreciates the wonderfully
expressive power of the word ''wibble''!

All best

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20091104/353c0c0c/attachment.html>

On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <apremdas at gmail.com>
wrote:
>
> Personally I now think nested steps are evil - but thats another story :)
It sounds like an entertaining one.  I''d love to hear why sometime.
(Though whether the right place for it would be here or the Cucumber
list, I couldn''t say.)

> Having said all this I haven''t actually done this in practice yet,
going to
> try it on my next view.
Please share what you find out.  Particularly if you discover a way to
do them that doesn''t make them feel like more work.  >8->

> By the way its nice to find a fellow soul who appreciates the wonderfully
> expressive power of the word ''wibble''!
Of course!  They wobble, but they don''t fall down.  >8->


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <sfeley at gmail.com> wrote:
> On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <apremdas at
gmail.com> wrote:
> >
> > Personally I now think nested steps are evil - but thats another story
:)
>
> It sounds like an entertaining one.  I''d love to hear why
sometime.
> (Though whether the right place for it would be here or the Cucumber
> list, I couldn''t say.)
>
I''ll pipe in since it''s here on this list at the moment:

I won''t go as far as to say that nested steps are evil, but I
don''t really
like to use them myself because they do conflate two levels of abstraction.
I''d sooner have two steps delegate to a helper than one step delegate
to
another.

FWIW,
David

> > Having said all this I haven''t actually done this in practice
yet, going
> to
> > try it on my next view.
>
> Please share what you find out.  Particularly if you discover a way to
> do them that doesn''t make them feel like more work.  >8->
>
>
> > By the way its nice to find a fellow soul who appreciates the
wonderfully
> > expressive power of the word ''wibble''!
>
> Of course!  They wobble, but they don''t fall down.  >8->
>
>
> --
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> 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/20091104/d8edb113/attachment.html>

I have had this thread starred since I first saw it... finally a few
minutes to participate in our community! It''s been too long!
> My question is this: In a world with Cucumber what is the value of
> view specs?
I''ve used view specs as a learning tool to help folks (including
myself) "get" the whole separation of concerns concept between views
and how they get their data.

In my own personal journey writing examples against views helped me
transition to a better developer. A lot of pain I saw developing real
code early on but I couldn''t understand why suddenly came into focus
when the same pain was experienced writing those view examples.

This was long before Cucumber, and I must admit, I love Cucumber. For
most things view related I find it my first tool of choice since I
like to ensure things are there as a result of the app doing something
(or the user doing something to it)!

Personally I''ve noticed quite a bit of overlap between how I''d
structure my view specs and how I structure some Cucumber steps. I
tend to write both semantically and I try to focus on particular
sections of the page rather than just on content. So if there should
be a leaderboard widget with the top 3 scorers listed I don''t have
steps like:

  Then I see "Bob"
  And I see "Mary"
  And I see "Fred"

To me those are pretty worthless steps. What if you''re logged in as
"Bobby"? Okay, I know that might seem like a far cry, but this has
actually happened (at least to me). Where information that seemed
unique at the time ended up not being so unique has the app involved
into a smorgus board of social networking mashups. And nothing is
worse than a false positive. Instead though I''d write:

  Then I see the top 3 scorers in the leaderboard are:
     | 1 | Bob  |
     | 2 | Mary |
     | 3 | Fred |

And in my step definition I''d have something similar to:
   within ".leaderboard" do
     response.should have_selector(".position", :content => 1)
     response.should have_selector(".name", :content =>
"Bob")
   end

This is actually the same exact code I would put in my view specs. The
only difference is the setup. Rather than using Cucumber''s Given/When
steps to set the page up, in a view spec I''d do something similar to:

   before(:each) do
     @bob, @mary, @fred = people("Bob", "Mary",
"Fred")
     assigns[:top_scorers] = [@bob, @mary, @fred]
   end

At the end of the day I find myself following the same practices that
I did with view specs, I just utilize Cucumber a lot more to make them
run. Now there are things I like to write view specs for that I don''t
think are very well-suited for cucumber scenarios.

   * site-wide navigation headers and footers
   * views which display polymorphic data (like system event logs)

For me these things are less pertinent to a single feature. And I
enjoy the confidence of knowing navigation headers and footers are
rendering the proper links. I''ve also gone and added super small view
specs that look like this:

  describe "projects/show.html.erb"
    should_render_navigation_partial
  end

I have a higher level of confidence that each the application-wide
systematically applied navigation is showing up on all of the pages
its supposed to. Scenarios suck for this kind of thing IMO. Just like
scenarios suck for ensuring resources are protected by logins or
permissions. I personally get a lot more confidence (and a lot less
boilerplate redundancy in some scenarios) with ensuring that an action
won''t run when the person doesn''t have a said permission.
It''s just to
easy to declare in a controller spec and feel super confident:

   describe ProjectsController do
      # generic login
      should_require_login :get

      # privilege specific
      should_require_privilege :get, :privilege => [:foo, :bar, :baz]
   end

When there are many permutations of a thing to provide examples for I
find lower level specs are better for broader confidence (because you
control the low level inputs) than a high level tool like Cucumber''s
scenarios. Although I did watch a screen cast recently on some Obtiva
guys driving ruby class creation with scenarios.

View specs and cucumber scenarios have another thing in common though.
They can both be brittle if you''re not writing semantic markup and
instead focusing on the literal structure of the page (ie: "div ul >
li p + a"). Writing non-semantic markup in Cucumber will succumb to
same evil has writing non-semantic markup in view specs -- unnecessary
maintenance time.

> In the community (railscamp, for example) there are a fair number of
> people using Cucumber and skipping view specs, but still speccing
> controllers, models, tricky view helpers and so on.
Cucumber definitely overlaps with view specs and in many cases
Cucumber is a better choice for many reasons. But I still find times
where I write or would like to (if I''m not on a project with rspec and
view specs) a view spec. In the past few year what I write a view spec
has gone down considerably.
> Why? Because they don''t find them helpful. Indeed they are seen as
a
> waste of time (money) not only duplicating Cucumber coverage, but also
> introducing a high-maintenance example group which designers (who
> don''t run tests) will frequently break.
Some of this goes to the makeup of the team as David pointed out, but
in general if you are wasting money writing doing anything unnecessary
than stop doing it. If the makeup of your team consists of designers
who aren''t able/willing to run specs and/or know how to fix them then
that is something to be considered. Also, if you''re duplicating
considerable amounts of outcome verification between Cucumber and the
view specs, then stop. If you get the coverage with your scenario then
let those drive the implementation.

In some cases you may find the language of the scenarios is more high
level and leaves out some details that should show up on a page which
you want to get some coverage against. If it doesn''t make sense to
keep adding things to scenarios view specs are a viable option. In
addition to the language of the scenario this may also depend on who
owns the scenarios. It''s much easier to use scenarios to cover a lot
detail when developers own them.

At the end of the day I would recommend utilizing view specs until you
get a good hang of them, maybe even on a personal project. That way if
you come across a situation where it might be applicable then you''ll
have the knowledge to know to use that tool. If you find Cucumber
meets your needs then you''ll be able to make that decision, empowered
with knowledge, and you''ll be able to contribute to your team with
more thoughtful ideas on how to organize scenarios, step definitions,
views, and specs in a way that maximizes communication, productivity,
confidence, and regression.


-- 
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)

On Nov 4, 5:30 pm, David Chelimsky <dchelim... at gmail.com>
wrote:
> On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <sfe... at gmail.com>
wrote:
> > On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <aprem... at
gmail.com> wrote:
>
> > > Personally I now think nested steps are evil - but thats another
story :)
>
> > It sounds like an entertaining one.  I''d love to hear why
sometime.
> > (Though whether the right place for it would be here or the Cucumber
> > list, I couldn''t say.)
>
> I''ll pipe in since it''s here on this list at the moment:
>
> I won''t go as far as to say that nested steps are evil, but I
don''t really
> like to use them myself because they do conflate two levels of abstraction.
> I''d sooner have two steps delegate to a helper than one step
delegate to
> another.
>
> FWIW,
> David
>
I''ll chime in also as to why I really dislike burying details like
that in the steps file.  Nobody but dev plays around with the lower
layers and the step files in particular.  Potentially everyone in the
business may have a hand in the ''feature'' definition, or maybe
need to
see or modify it at a later time.  Also a Dev or tester reviewing
things to see ''how should it work'' gets everything high level
in one
place (the feature file) instead of having to chase down into multple
levels of step files ( an exercise reminding one of why we hate
spaghetti code) to find the details that matter up at the UI or
potentially integration test level.

Remember Rspec/Cucumber are all about implementing BDD..  Part of BDD
is that more than just the folks in Dev will be looking at what''s done
at the ''feature'' level.   If you bury the details of something
inside
the step file, then nobody outside of dev can play along, and that
defeats a large part of the purpose of BDD.

If it is important to the business that a particular field be on that
page, then you ought to have it expressed in the feature and not
buried in the steps.   Consider something like

''Scenario: User reviews their profile details''
Given I am logged in as: <user>
When I click the link: view profile
Then I should see my profile details.

How much more value to the business (and clarity to those implementing
the feature) is created if we were to instead have something more
like:

....
Then I will be on the page: User Profile
and I will see <field1> identified as <field1label> containing
<value1>
and I will see <field2> identified as <field2label> containing
<value2>
  etc

The <> items could either of course be spelled out, or they could be
parameters in a scenario outline''s examples section.

--Chuck

2009/11/5 Chuck van der Linden <sqapro at gmail.com>
> On Nov 4, 5:30 pm, David Chelimsky <dchelim... at gmail.com> wrote:
> > On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <sfe... at
gmail.com> wrote:
> > > On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <aprem... at
gmail.com>
> wrote:
> >
> > > > Personally I now think nested steps are evil - but thats
another
> story :)
> >
> > > It sounds like an entertaining one.  I''d love to hear
why sometime.
> > > (Though whether the right place for it would be here or the
Cucumber
> > > list, I couldn''t say.)
> >
> > I''ll pipe in since it''s here on this list at the
moment:
> >
> > I won''t go as far as to say that nested steps are evil, but I
don''t
> really
> > like to use them myself because they do conflate two levels of
> abstraction.
> > I''d sooner have two steps delegate to a helper than one step
delegate to
> > another.
> >
> > FWIW,
> > David
> >
>
> I''ll chime in also as to why I really dislike burying details like
> that in the steps file.  Nobody but dev plays around with the lower
> layers and the step files in particular.  Potentially everyone in the
> business may have a hand in the ''feature'' definition, or
maybe need to
> see or modify it at a later time.  Also a Dev or tester reviewing
> things to see ''how should it work'' gets everything high
level in one
> place (the feature file) instead of having to chase down into multple
> levels of step files ( an exercise reminding one of why we hate
> spaghetti code) to find the details that matter up at the UI or
> potentially integration test level.
>
> Remember Rspec/Cucumber are all about implementing BDD..  Part of BDD
> is that more than just the folks in Dev will be looking at what''s
done
> at the ''feature'' level.   If you bury the details of
something inside
> the step file, then nobody outside of dev can play along, and that
> defeats a large part of the purpose of BDD.
>
> If it is important to the business that a particular field be on that
> page, then you ought to have it expressed in the feature and not
> buried in the steps.   Consider something like
>
> ''Scenario: User reviews their profile details''
> Given I am logged in as: <user>
> When I click the link: view profile
> Then I should see my profile details.
>
> How much more value to the business (and clarity to those implementing
> the feature) is created if we were to instead have something more
> like:
>
> ....
> Then I will be on the page: User Profile
> and I will see <field1> identified as <field1label> containing
> <value1>
> and I will see <field2> identified as <field2label> containing
> <value2>
>  etc
>
> The <> items could either of course be spelled out, or they could be
> parameters in a scenario outline''s examples section.
>
> --Chuck
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Couldn''t agree less :-) , although alot of that depends on the
business.
There are many problems with the sort of scenarios you prefer

1) They are very fragile - change a label and it breaks. A business will
review the application not the feature. When I change the label who fixes
the feature, and why should I have to run 30 minutes of features to change
one label!

2) You have to get detail correct before you know the context. As a business
person how do I know what details should be in the user profile.

3) It places the responsibility for trivial and obvious decisions with the
business people. And makes them make these decisions before they are ready.
Its much easier to decide what should be on the profile page when you can
see it and navigate to it. And as a business it is cheaper and far more
effective to trust your development team rather than micro-manage them to
the nth degree.

4) With an application of any size the amount of detail these type of
scenarios generates soon removes and chance of the business actually reading
or reviewing the features. Any chance of getting an overview of what the
application does, or even readable reports of what works and what
doesn''t is
lost.

Dev''s and testers are perfectly capable of looking at step definitions
and
working with them. Business people (at least the ones I know and have
experienced) are much better at telling you want they want by providing
feedback from the application itself than by doing any sort of up front
work. One of the elegant parts of BDD is that by writing simple succinct
features business can get you quickly into a feedback loop. It is much
easier to create

Feature
As a user
I want to have a profile
So I can stop you spamming me

Scenario
When I view my profile
I should be able to stop you spamming me

and start iterating around that, than to create some big feature that
specifies different labels for mailings and whether to use radio button or
checkboxes. It is also much easier for the business to come back to a 5 line
profile feature, and review this by looking at the application, than to
review a 200 line profile feature. This is an Agile process we''re
supposed
to be working with after all.

All best

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20091108/acfe77bb/attachment.html>

IMHO steps can test everything that view specs can test,
but in a much faster and will less effort.

You don''t have to build a huge feature to test
a complex view, you can just split it into different
scenarios.  In the profile example of a social site,
you could have a scenario for friend, one for personal
info, one for messages in your wall etc, etc. All
nice and clear for developers, designers and business
man.

Regarding the detail of features, I think if that
if someone in the business does not get involved
enough to look at the features and agree on them,
them before starting with the implementation then
we don''t have a commitment.  If the president
of the company is too busy, someone else
should be in charge of agreeing on the stories.
We are not talking about implementation details,
we are talking about the behavior of the application.

That said, I think there is a missing interface
in features, where one should be able to reduce
detail or show it.  Just like nesting steps
but not in step files, instead they should be in
the feature file.  For example:

When I fill in the form correctly

Every nested step should be visible in the feature file,
or hidden depending on what the person reading the
feature is most interested in seeing.

Footers and other layout checks, I simply test
them in the main page, I think that covers the
requirement that they will be seen in all pages.

Zack, you example:

  Then I see the top 3 scorers in the leaderboard are:
     | 1 | Bob  |
     | 2 | Mary |
     | 3 | Fred |

Is a very good one.  See the beauty of steps,
is that you don''t have to write a single line of
ruby to test this. You can just reuse steps.
For that we would have to re-write this step
to be more reusable, something like this:

Scenario: Top Scores
  Given the following users:
        | name | score |


On Nov 8, 1:55?am, Andrew Premdas <aprem... at gmail.com>
wrote:
> 2009/11/5 Chuck van der Linden <sqa... at gmail.com>
>
>
>
>
>
> > On Nov 4, 5:30 pm, David Chelimsky <dchelim... at gmail.com>
wrote:
> > > On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <sfe... at
gmail.com> wrote:
> > > > On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <aprem...
at gmail.com>
> > wrote:
>
> > > > > Personally I now think nested steps are evil - but
thats another
> > story :)
>
> > > > It sounds like an entertaining one. ?I''d love to
hear why sometime.
> > > > (Though whether the right place for it would be here or the
Cucumber
> > > > list, I couldn''t say.)
>
> > > I''ll pipe in since it''s here on this list at
the moment:
>
> > > I won''t go as far as to say that nested steps are evil,
but I don''t
> > really
> > > like to use them myself because they do conflate two levels of
> > abstraction.
> > > I''d sooner have two steps delegate to a helper than one
step delegate to
> > > another.
>
> > > FWIW,
> > > David
>
> > I''ll chime in also as to why I really dislike burying details
like
> > that in the steps file. ?Nobody but dev plays around with the lower
> > layers and the step files in particular. ?Potentially everyone in the
> > business may have a hand in the ''feature''
definition, or maybe need to
> > see or modify it at a later time. ?Also a Dev or tester reviewing
> > things to see ''how should it work'' gets everything
high level in one
> > place (the feature file) instead of having to chase down into multple
> > levels of step files ( an exercise reminding one of why we hate
> > spaghetti code) to find the details that matter up at the UI or
> > potentially integration test level.
>
> > Remember Rspec/Cucumber are all about implementing BDD.. ?Part of BDD
> > is that more than just the folks in Dev will be looking at
what''s done
> > at the ''feature'' level. ? If you bury the details of
something inside
> > the step file, then nobody outside of dev can play along, and that
> > defeats a large part of the purpose of BDD.
>
> > If it is important to the business that a particular field be on that
> > page, then you ought to have it expressed in the feature and not
> > buried in the steps. ? Consider something like
>
> > ''Scenario: User reviews their profile details''
> > Given I am logged in as: <user>
> > When I click the link: view profile
> > Then I should see my profile details.
>
> > How much more value to the business (and clarity to those implementing
> > the feature) is created if we were to instead have something more
> > like:
>
> > ....
> > Then I will be on the page: User Profile
> > and I will see <field1> identified as <field1label>
containing
> > <value1>
> > and I will see <field2> identified as <field2label>
containing
> > <value2>
> > ?etc
>
> > The <> items could either of course be spelled out, or they
could be
> > parameters in a scenario outline''s examples section.
>
> > --Chuck
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/rspec-users
>
> Couldn''t agree less :-) , although alot of that depends on the
business.
> There are many problems with the sort of scenarios you prefer
>
> 1) They are very fragile - change a label and it breaks. A business will
> review the application not the feature. When I change the label who fixes
> the feature, and why should I have to run 30 minutes of features to change
> one label!
>
> 2) You have to get detail correct before you know the context. As a
business
> person how do I know what details should be in the user profile.
>
> 3) It places the responsibility for trivial and obvious decisions with the
> business people. And makes them make these decisions before they are ready.
> Its much easier to decide what should be on the profile page when you can
> see it and navigate to it. And as a business it is cheaper and far more
> effective to trust your development team rather than micro-manage them to
> the nth degree.
>
> 4) With an application of any size the amount of detail these type of
> scenarios generates soon removes and chance of the business actually
reading
> or reviewing the features. Any chance of getting an overview of what the
> application does, or even readable reports of what works and what
doesn''t is
> lost.
>
> Dev''s and testers are perfectly capable of looking at step
definitions and
> working with them. Business people (at least the ones I know and have
> experienced) are much better at telling you want they want by providing
> feedback from the application itself than by doing any sort of up front
> work. One of the elegant parts of BDD is that by writing simple succinct
> features business can get you quickly into a feedback loop. It is much
> easier to create
>
> Feature
> As a user
> I want to have a profile
> So I can stop you spamming me
>
> Scenario
> When I view my profile
> I should be able to stop you spamming me
>
> and start iterating around that, than to create some big feature that
> specifies different labels for mailings and whether to use radio button or
> checkboxes. It is also much easier for the business to come back to a 5
line
> profile feature, and review this by looking at the application, than to
> review a 200 line profile feature. This is an Agile process we''re
supposed
> to be working with after all.
>
> All best
>
> Andrew
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On 4 Nov 2009, at 15:56, Andrew Premdas wrote:
> 2009/10/29 nruth <nick.rutherford at gmail.com>
> Hi Guys
>
> I''m going to put the cat amongst the pigeons here in the hope of
some
> clarity falling out of the sky on me.
> My question is this: In a world with Cucumber what is the value of
> view specs?
>
> In the community (railscamp, for example) there are a fair number of
> people using Cucumber and skipping view specs, but still speccing
> controllers, models, tricky view helpers and so on.
>
> Why? Because they don''t find them helpful. Indeed they are seen as
a
> waste of time (money) not only duplicating Cucumber coverage, but also
> introducing a high-maintenance example group which designers (who
> don''t run tests) will frequently break.
>
> These people aren''t stupid. They''re producing working
apps. I don''t
> claim that their work cycle is perfect: this is about utility and
> efficiency, or about being lazy or avoiding boredom, if you prefer.
>
> I''ve been working in a mixed environment, with an existing project
> which uses rspec and cucumber (sans view specs) and my own green field
> app for a different client.
> I''ve been following the BDD approach prescribed by the RSpec book
(or
> so I think). This works, and has produced a lot of LOC.
>
> I''ve not worried, as it has given me plenty of practice with the
> various arms of rspec, webrat, and other tools.
> Now that I''m more comfortable with them things are starting to get
> tiresome, especially duplication, and I''m worried I''m
creating a
> monolith. Too many specs => TLDR ?
>
> What should I try using view specs for? Why are they better than
> cucumber for this?
>
> "Driving views through examples helps us think about what the view
> needs in order for it to do its job. It encourages us to write the
> code we wish we had to fulfil those needs."
>
> I''m not sure how this is any different to what I do in the outer
> circle with Cucumber. If I write an explicit scenario like
> http://gist.github.com/221004 then I already know what the view needs
> to let me do.
>
> If I write something more broad-brush (which you will do, if quickly
> sketching out features during a design meeting) like "When I add a
> page link" I have to then define that step so it goes red (or, heaven
> forbid, green). But to write that step definition I have to know how I
> can interact with the page. This example actually comes from a broad-
> brush step being expanded in the scenario itself rather than hiding it
> away in a step definition, but that''s a different subject.
>
> I''m specifying the page''s behaviour in the scenario, or
in the step
> definition. Why duplicate this process with a view spec?
>
> I keep coming back to the introduction of chapter 23 in the RSpec book
> but don''t seem to be getting anywhere from it.
>
> For the time being I''m going to keep writing view specs, but try
to
> make them lighter and cut some of the dead wood by describing unusual
> or interesting behaviour rather than all behaviour.
>
> I''d love to hear your thoughts.
>
> Regards
>
> Nick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> Currently I don''t do view specs, but I''m beginning to see
a use for
> them. This is all to do with a recent change change in my thinking  
> about features. In addition to all the other things features do, I  
> am now seeing them as a map to what the "business" wants from the
> application. This map works best if it is clear and simple (a bit  
> like the London tube map). Putting lots of view details in the  
> features (and I should see a wibble field etc. ...) pollutes this  
> map with clutter that is not relevant to the "business" context.
So
> view specs seem like a really good place to spec all this detail.
>
> Another benefit of this is that the view specs might end up as  
> another map that is useful to designers and front end developers.
>
> I''ve been thinking about features, specs and even code as maps  
> recently. It provides a really good explanation of why names and  
> description are so important.
>
> Andrew
I''ve been pretty vocal on here about my dislike for view specs, but  
here''s another strength they do have: they force you to think about  
the of the *interface* between the view and the rest of the app. When  
you''re building a page that''s rich in content[1] it becomes
important
to have a bright line drawn between the presentation code and the  
rest. A lot of the view specs we wrote in the early days at Songkick,  
frankly, sucked in this regard - they didn''t listen to the tests and  
just mocked away like crazy across really broad interfaces, walking  
model associations and allsorts. These are the brittle tests I took  
pleasure in deleting each time we replaced them with a broad-brush  
cuke. What we missed of course was the design guidance we could have  
had all along if only we''d listened to the tests...

[1]http://www.songkick.com/artists/395944-radiohead

cheers,
Matt

http://mattwynne.net
+447974 430184