[rspec-users] Philosophical questions

Pat Maddox pergesu at gmail.com
Thu Sep 13 18:10:52 EDT 2007

On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:
>  Disclaimer: The following are observations by a relatively new user (couple
> of weeks) of RSpec and not intended as RSpec trollbait.  Also, forgive me if
> similar topics have been discussed elsewhere on the mailing list.  I at
> least did the due diligence of a quick search.
>  That said...
>  I've been positively thrilled with RSpec for use outside of Rails.  It has
> been in my attempts to use it within Rails that I have begun to question
> whether and how it can buy me much more than Test::Unit.
>  I recently began using RSpec to drive the design, in BDD fashion, of a
> Rails app.  Believing that behavior is best measured from the user's
> experience, I started by writing a View spec.  I considered this a top-down
> approach.  Were I still using Test::Unit, I likely would have started in the
> same place that I usually do out of habit: the Model.
>  However, the more googling that I've done, the more that I noticed that
> most RSpec articles, where they addressed Rails, were primarily focused on
> the Model.  I began to wonder, "are people using RSpec much like people were
> using Test::Unit?"  I've seen that some people eschew View Specs.  However,
> in lieu of that, how does one spec the interface that should, in theory,
> drive the design of the application?
>  Ultimately, I'm left with similar perspective to Jordan's: View specs will
> be brittle.  They'll span multiple Behaviors as there will be at least one
> per action -- leading me to wonder if BDD, or at least RSpec, is necessarily
> the best way to try to spec the View.  However, Controllers and Models seem
> as though they would work reasonably well.
>  Can anyone recommend some approaches for tackling BDD starting from the
> View down?
> Thanks,
> Evan
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Hi Evan,

I think you have the right idea about approaching specification from
the user's viewpoint (or more appropriately, as David C said, business
value).  It just seems like you're not completely familiar with the
tools that RSpec provides.  Nothing wrong with that, because one of
the most important tools still hasn't been officially released!

View specs are for unit testing your view, not for exercising
functionality.  In fact they shouldn't do very much at all.  They
should be pretty simple...make sure that certain attributes from an
object are being displayed, perhaps how some of the markup is
structured, etc.  That can be brittle, and will become painfully so if
you specify too much.  You'll want to specify the bare minimum it
takes to get the job done.

Others have mentioned Story Runner, which is a new feature of RSpec.
I'm pretty jazzed about it, because it's a very lightweight tool for
acceptance tests.  The structure is clean, it just makes sense to me.
I wrote an introduction which you can find at
 It also has links to some of Dan North's articles which are a great
resource for really getting BDD.

As far as tackling BDD from the top down...for me, it all starts with
a Story.  This can be a bit tough if you don't write user stories to
define features, and instead just get told "hey we should add this."
However I've found that writing an initial user story forces me to
really clarify what a feature means to our product.  Also Story Runner
makes it incredibly easy to share the stories with others.  If one of
our customers tells me something doesn't work right, but I think it
does, I can show him the story I wrote.  We've already resolved an
issue like this...I showed him the story, he said that he was making
different assumptions.  I coded those up into the story and off we

I hope you check out Story Runner, it's a really cool tool.  If your
development philosophy is about creating business value, then it
should totally vibe with you.  From there you use the finer-grained
aspects of RSpec to achieve that business value with code that doesn't
drive you insane :)


More information about the rspec-users mailing list