[rspec-users] Philosophical questions

David Chelimsky dchelimsky at gmail.com
Wed Sep 12 18:15:43 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.

I like to start w/ integration tests before anything exists at all.
You can do that w/ Rails' Integration Tests or Story Runner (if you're
using RSpec's trunk).

Next, I hit a view. View specs DO get brittle fast, and such warnings
are useful advice, however that does not mean you shouldn't do them.
If you change a view template and a loose an important form element
then the form doesn't work. That's broken software, brittle specs or
not. If you don't want broken software, then spec the views - but ONLY
the stuff that actually has business value.

Once the view is sufficiently spec'd and the specs are passing, I know
what the controller needs to supply, so I start spec'ing the
controller. And on down to models.

I think the reason there's so much posted about spec'ing models is
because there's so much controversy over "the right way" to do it. The
sad fact is that spec'ing models sucks if you're trying to keep "pure
BDD" (can someone explain what that means?) because it means you end
up either testing stuff that's already tested by Rails (a TDD no-no)
or you're hitting the database (another TDD no-no). On the flip side,
if you're trying to get things to go fast and keep things isolated,
then you end up violating BDD sensibilities, which also sucks.

The thing is that most of the debate has been about aesthetics and
hypotheticals. We'll learn a lot more over time as people who espouse
different approaches write about how the different approaches effect
the long term.

The whole reason we started the BDD discussion was because ppl were
trying TDD and not getting stuff done because they kept
over-engineering themselves down rat holes! In the end, that's the
most important measure: Does your approach help you get stuff done? If
an approach isn't helping you getting stuff done, then it's just BDC:
Bullshit Driven Catastrophe.

That's not to say that the philosophy isn't important. I, personally,
love talking about philosophy. It helps me to understand why I
gravitate towards the things I do. But keep in mind that
philosophy/theory is usually there to try to explain natural
phenomena. Design patterns just were - they weren't created. They were
then recognized, documented, and now instead of solving problems with
them people create problems with them by thinking about using them
before there's a problem to solve. They were never there to solve
problems in advance. They were there to solve problems you were
actually having.

Same w/ approaches to testing and developing software. Agile isn't all
that agile if we're all finding "best practices" and applying them
like a bunch of blind followers of some religion. "We have come to
value individuals and interactions over processes and tools," yet
we're always becoming slave to the next tool rather than becoming its
master and sticking it in our tool belt.

Wow - that was an unexpected rant. Thanks for prompting it!!! Guess
the whole religion thing has been on my mind for a while.

Summing up - the series of steps I described above is what I *usually*
do because I know it works for me and the way I work. But I don't do
that 100% of the time, and I certainly don't feel bad when I break
that pattern. It's just a great tool to have lying around.

Cheers,
David

>
>  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
>


More information about the rspec-users mailing list