[rspec-users] Philosophical questions

Evan David Light evan at tiggerpalace.com
Wed Sep 12 15:55:20 EDT 2007

	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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070912/cef3e0b7/attachment.html 

More information about the rspec-users mailing list