On 4 Nov 2009, at 15:56, Andrew Premdas wrote:
2009/10/29 nruth <nick.rutherf...@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.
Regards
Nick
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
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.
Andrew
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[1] 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...
[1]http://www.songkick.com/artists/395944-radiohead
cheers,
Matt
http://mattwynne.net
+447974 430184
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
