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.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs