[rspec-users] MVC testing vs. models & Webrat+RailsStory?

Kyle Hargraves philodespotos at gmail.com
Fri Jun 20 14:09:33 EDT 2008


On Thu, Jun 19, 2008 at 11:56 AM, Christopher Bailey
<chris at cobaltedge.com> wrote:
> 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.
>
> - 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 have not attempted to set up autotest + stories, but it should be
possible to set up autotest to watch stories/**/*.story and rerun the
corresponding story when *that* changes; like you say, it'd be
difficult to map implementation files to their stories.

I do miss autotest at times, but up+enter on your console to rerun
some focused stories is not bad at all. I use a command-line runner
without the maintenance requirements of the *.rb runner files
(http://github.com/pd/story), so I can pretty easily select the
individual foo.story, a full feature, or any mix I want, then just
rerun those when I'm ready. Actually, I save files so often that
waiting on the stories to catch up would probably be annoying.

> 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.

As Josh Knowles also said, dropping the unit level specs has turned
out to be a mistake. I wouldn't say it's a BIG mistake, and the main
issue is just waiting too damned long before you are comfortable
pushing your code (which leads to saying "ah screw it" and then "ah
crap it failed on CI" and then ...). But a mistake nonetheless.

If I started a fresh project today, I would still probably ignore view
specs early on; they're cumbersome and take a lot of tweaking when
you're just barely figuring out what it is you want to accomplish.
Once your ideas solidify a bit, tho, view specs using stub_model()
seem perfectly good these days. For controller specs, I think I'd
continue to do exactly what I'm already doing: spec the deviations
from the pretty-much-scaffolding REST controllers, and wrap up
authentication/authorization specs in a tidy DSL to generate that
stuff for me. Thin controllers deserve thin controller specs! =)

> 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
> effect a button press that does its work via JavaScript.  I can move
> 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.).

Yes, I take extensive advantage of that. So you can click 'edit' next
to something on the screen, which unhides a form, but the form is
already on the page; webrat is entirely unaware of the CSS and will
just fill it out and submit it. It's a minor headache when there are
10 'edit' links and 10 corresponding forms, cuz you'll need to dig
through and be sure to fill out the right fields. Other than that,
tho, nothin but sunshine.

k


More information about the rspec-users mailing list