[rspec-users] [BDD] View specs and cucumber -- duplication of effort?
dchelimsky at gmail.com
Thu Oct 29 10:19:15 EDT 2009
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
>> 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
>> 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
>> 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
>> 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.
> 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.
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
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
More information about the rspec-users