[rspec-users] [BDD] View specs and cucumber -- duplication of effort?
matt at mattwynne.net
Mon Nov 9 16:03:28 EST 2009
On 4 Nov 2009, at 15:56, Andrew Premdas wrote:
> 2009/10/29 nruth <nick.rutherford at gmail.com>
> 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 also
> 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 field
> 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 it
> 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 book
> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
> Currently I don't do view specs, but I'm beginning to see a use for
> them. This is all to do with a recent change change in my thinking
> about features. In addition to all the other things features do, I
> am now seeing them as a map to what the "business" wants from the
> application. This map works best if it is clear and simple (a bit
> like the London tube map). Putting lots of view details in the
> features (and I should see a wibble field etc. ...) pollutes this
> map with clutter that is not relevant to the "business" context. So
> view specs seem like a really good place to spec all this detail.
> Another benefit of this is that the view specs might end up as
> another map that is useful to designers and front end developers.
> I've been thinking about features, specs and even code as maps
> recently. It provides a really good explanation of why names and
> description are so important.
I've been pretty vocal on here about my dislike for view specs, but
here's another strength they do have: they force you to think about
the of the *interface* between the view and the rest of the app. When
you're building a page that's rich in content it becomes important
to have a bright line drawn between the presentation code and the
rest. A lot of the view specs we wrote in the early days at Songkick,
frankly, sucked in this regard - they didn't listen to the tests and
just mocked away like crazy across really broad interfaces, walking
model associations and allsorts. These are the brittle tests I took
pleasure in deleting each time we replaced them with a broad-brush
cuke. What we missed of course was the design guidance we could have
had all along if only we'd listened to the tests...
More information about the rspec-users