[rspec-users] [OT] Object Mother vs Test Data Builder (was Jay Fields' blog on developer testing)
cwdinfo at gmail.com
Fri Feb 6 22:00:54 EST 2009
On Feb 6, 2009, at 10:21 AM, Scott Taylor wrote:
> On Feb 6, 2009, at 12:50 PM, Stephen Eley wrote:
>> On Fri, Feb 6, 2009 at 12:17 PM, Fernando Perez <lists at ruby-
>> forum.com> wrote:
>>> The next big step will be specing controllers, as it is more painful
>>> than models, but now that my controllers are ripped I guess it
>>> will be
>> I've stopped. Mostly because of the question Jay asks in that
>> article: "Why are you testing?" I realized I had *no idea* why I was
>> testing controllers, except that I had been lurking here and reading
>> the RSpec docs and assumed that was the Way It Was Done. Finessing
>> all those mocks and stubs does chew up major time, and I noticed that
>> the controller code I was spending all that time writing stubs around
>> wasn't typically code that broke. Most controllers for most apps are
>> so boilerplate that if you can trust your framework (Rails or Merb)
>> you can probably trust the controller.
> I've found that sometimes writing a very *simple* controller test,
> which hits the db is a better solution when you don't have the time
> and resources for a full cucumber story.
> Mocking a controller without some sort of macros (like rspec-on-
> rails-on-crack) is just too laborious and repetitive for my liking.
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?
More information about the rspec-users