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:

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

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

* the final specs for a view aren’t very explicit and it can be
to figure out all the things a view does without tracing back the

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).


  • It’s explicit and easy to tell what each view does.


  • 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?

I don’t have a lot of experience yet with the view spec’ing, but I do
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
using the same partial, then I would extract the view tests that deal
the partial and use those as tests for the partial.