View spec'ing style

Testing RSpec
1

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?

2

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