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

Christopher Bailey chris at cobaltedge.com
Thu Jun 19 12:58:37 EDT 2008

Just found answer to one of my questions below on being able to run
stories in TextMate.  The new bundle for stories looks cool:

On Thu, Jun 19, 2008 at 9: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.
> 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
> a problem.
> 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
> 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.).
> 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
>>> 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> --
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com

Christopher Bailey
Cobalt Edge LLC

More information about the rspec-users mailing list