On Thu, Jun 19, 2008 at 9:31 AM, Christopher Bailey
<[EMAIL PROTECTED]> wrote:
> Specifically, I'm wondering, or contemplating, if I do unit tests for
> my models, and then I use WebRat plus RailsStory, do I even need to
> then do functional testing of my controllers and views? I can see
> that I might want to do some particular view testing that ensured
> certain elements were on a page or something, but in terms of actually
> testing the workings of my app/site, it seems model unit tests
> combined with RailsStory+Webrat will do a pretty darn thorough job. I
> would then consider going to Selenium to test some of the detailed
> JavaScript as needed.
>
> Thoughts? What am I missing, or what are the downsides of such an approach?
In the project I'm working on, we lean pretty heavily on model/helper
specs and webrat-driven plain text stories.
We still do *some* controller specs, but only in those instances where
we deviate from the standard REST design, or to test authentication
requirements. With a custom it_should_... example generator, that can
be as simple as:
describe FooController do
describe "GET :index" do
it_should_require_admin_access(:get, :index)
end
end
We currently have no view specs at all, though I am beginning to
regret that decision somewhat. Initially we avoided them because the
effort required to mock everything out wasn't jiving well with rapid
prototyping, but I'm considering going back and pushing some things
into view specs using stub_model(). There are a lot of simple
requirements that are a good fit for view specs which we are currently
doing in the user stories, solely because the infrastructure was
already there.
As far as controllers go, I wouldn't say we've seen any downside to
relying on stories instead of isolated specs; I'm sure you've seen how
90% of every controller spec ends up looking the same, and they start
to be a headache to maintain. Maybe the shoulda-esque rspec plugins
out there would help, but when I can easily just exercise the full
stack, I haven't bothered to try. I saw one big *win* of not testing
controllers in isolation just this week, though, when I had to shift a
lot of an application's view paths around; with standard controller
specs, I would've been spending a lot of typing updating the render
expectations, but with stories it wasn't an issue: the right markup
either showed up or didn't.
The primary downside for us has been speed; it takes a few minutes to
run the full story suite. The ability to selectively run just a few
stories, and then a good CI server, alleviates that for the most part.
I always ramble too much so I'll stop here. HTH,
k
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
