On 06/02/2009, at 10:00 PM, s.ross wrote:
I did stop writing new controller specs, but we were discussing the
use-case for controller specs in the new Cukified world. Supposing
you write scenarios that pretty much describe your app, what could
possibly go wrong that a controller spec would catch but a cucumber
story pass? My environment is not using Selenium or Watir, so any
action that is Ajaxey potentially needs a controller spec example.
I'm less clear that routing needs to be in the specs, but shoulda
makes that stupid-simple, so it's a way to make sure I don't break
something embarrassing when I'm goofing around in routes.
I'm starting to think that Cucumber can do 90+% of the heavy
lifting, but for describing what kind of response a controller will
ship back (json or html), based on the request, user-agent specific
stuff. All that would probably have to happen in controller specs.
In response to Jay's post, I test what I'm afraid might fail. I test
it to clarify my thinking as I build it. So if it's important that a
controller return json in response to an XmlHttp request, then
that's part of the spec.
Does this sound reasonable?
When writing Cucumber stories and features for controllers, should you
cover every edge case? For example, should you write stories that feed
bad or missing data to your controllers, or should that be left to
RSpec?
-Nick
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
