Zach Dennis wrote: > That would be very difficult to do and to do well (with autotest or > RSpactor) since stories cover a complete vertical slice of the > application, and it'd be almost impossible to know what source file > (or method) affect will what stories.
Sure, I agree, but I think it would still be incredibly useful even if it ran a single scenario every time you edit that scenario - not necessarily the source files that the scenario would "operate" on. > Continuous integration works very well for this. Let another machine > pull an update (or you can push an update) and it runs the specs and > stories. When I was at Atomic Object I wrote a small growl notifier > which received updates from our continuous integration server telling > it when something failed. It was beautiful. Of course this was really > easy to write since the continuous integration server was written in a > way that allowed you to attach listeners (and remote monitors) to it > over the network. I've already got TeamCity (highly recommended) running for both stories and examples every time I check into SVN. I'm doing things as test-driven as possible , and more times than not it's a story driving development rather than a spec. Test driving things this way means I get to run the stories all the time, and a bit of automation would be awesome. Hell, I'd settle to just be able to execute a single scenario by hand at this point. Running an entire story is still too large for me sometimes =) -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
