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 <[EMAIL PROTECTED]> wrote: > 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 > -- Christopher Bailey Cobalt Edge LLC http://cobaltedge.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
