[rspec-users] MVC testing vs. models & Webrat+RailsStory?
chris at cobaltedge.com
Thu Jun 19 12:56:27 EDT 2008
Kyle, thanks much for sharing your experience. You mention the speed
and so on. I've read that it is slow. Question: does Autotest work
the same way with stories, or have a way to detect what file(s)
changed and run the appropriate stories, or because they're
integration tests, would it just re-run the entire story suite as it
really doesn't have a way to correlate source files to stories? I
presume the latter.
I guess what I'd wonder, in terms of dealing with the speed issue is:
- Can I run a single story via TextMate like I do with specs? That
would allow me to concentrate on one particular thing if I needed
quick turn around time.
- I just always have autotest running, and most of the time, I just
let it do its thing, listening for any failures (I use Mac's speech to
alert me :) So, the speed isn't so bad as I typically just keep
working until I hear a problem, then go fix that.
- I am a huge fan of CI servers, and have one setup for every project
I control. I do like to know my suite passes before I push my changes
up, but the CI server is a great way to ensure everything passes on a
clean system. I suppose if the story runner was really taking very
long times, that I'd be ok pushing and seeing if the CI server caught
I'd like to hear other's thoughts as well, but your experience seems
consistent with my theory of the direction I want to go: unit test
models and helpers, drop controller and view tests in favor of Webrat
+ RailsStory, and then, as needed drop in RSpec view tests for things
that can't be as efficiently/effectively tested in stories.
Final bit/question (for now ;-)... With Webrat, does it pay attention
to whether or not div's and such are hidden/displayed in terms of
whether it lets you enter values in them? In this particular project
I use a fair bit of disclosure style UI, where some fields are shown
after a use takes some other action or presses a button, etc. But
they're all there, just not visible. So, wondering if I can simply
tell Webrat to put data into them, and not worry about having to
to Selenium to handle that, but that's actually something I'm not
wanting to do yet (I've used it in the past, and it's just a ton of
overhead, truly slow, etc.).
On Thu, Jun 19, 2008 at 8:41 AM, Kyle Hargraves <philodespotos at gmail.com> wrote:
> On Thu, Jun 19, 2008 at 9:31 AM, Christopher Bailey
> <chris at cobaltedge.com> 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
>> 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)
> 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,
> rspec-users mailing list
> rspec-users at rubyforge.org
Cobalt Edge LLC
More information about the rspec-users