On Thu, Jun 19, 2008 at 11:56 AM, Christopher Bailey <[EMAIL PROTECTED]> 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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
