rspec users - Jan 2008 - View spec''ing style

I''ve been getting my head around view spec''ing lately for a
fairly
complex project that makes heavy use of partials in views and I have hit
up against a style puzzle.

I see two strategies for spec''ing views:

First:
  Develop detailed specs for each partial and then make sure that the
final view expects that the appropriate partials are included and used.

   Pros:
    * it''s DRY
    * you get a single point of failure if an expectation is not met

   Cons:
    * the final specs for a view aren''t very explicit and it can be
challenging
      to figure out all the things a view does without tracing back the
partials.

Second:
  Develop a set of specs for each view that explicitly expect the
important UI elements and treat the rest of the view as a black box
(i.e., you don''t care if a particular partial was rendered so long as
the relevant UI elements are there).

  Pros:
   * It''s explicit and easy to tell what each view does.

  Cons:
   * It''s not DRY.. you will get multiple points of failure if a
partial
     is changed.
   * More time consuming and it''s easy to miss an expectation in a
view.


So... What are people doing?  The first?  The second? or some
combination of the two?
-- 
Posted via http://www.ruby-forum.com/.

I don''t have a lot of experience yet with the view spec''ing,
but I do have
the first way I will start:

Spec a view from the outermost level and Treat extracted partials as a
hybrid of "Extract Method" and "Extract Class"
This means that I would spec out the top-most view, extract a partial to
remove duplication or enhance readability. If I find that two views start
using the same partial, then I would extract the view tests that deal with
the partial and use those as tests for the partial.

-Corey

On Jan 13, 2008 12:14 PM, Kevin Olbrich <lists at ruby-forum.com> wrote:
> I''ve been getting my head around view spec''ing lately for
a fairly
> complex project that makes heavy use of partials in views and I have hit
> up against a style puzzle.
>
> I see two strategies for spec''ing views:
>
> First:
>  Develop detailed specs for each partial and then make sure that the
> final view expects that the appropriate partials are included and used.
>
>   Pros:
>    * it''s DRY
>    * you get a single point of failure if an expectation is not met
>
>   Cons:
>    * the final specs for a view aren''t very explicit and it can be
> challenging
>      to figure out all the things a view does without tracing back the
> partials.
>
> Second:
>  Develop a set of specs for each view that explicitly expect the
> important UI elements and treat the rest of the view as a black box
> (i.e., you don''t care if a particular partial was rendered so long
as
> the relevant UI elements are there).
>
>  Pros:
>   * It''s explicit and easy to tell what each view does.
>
>  Cons:
>   * It''s not DRY.. you will get multiple points of failure if a
partial
>     is changed.
>   * More time consuming and it''s easy to miss an expectation in a
view.
>
>
> So... What are people doing?  The first?  The second? or some
> combination of the two?
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
http://www.coreyhaines.com
The Internet''s Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20080113/5be72eb4/attachment.html