On Sat, Aug 2, 2008 at 1:43 PM, Luis Lavena <[EMAIL PROTECTED]> wrote:
> One is the lack of possiblity to actually quit gracefully (they need > to trap INT and properly stop the DRb server. I just do rake spec:server:stop. This is necessary before running rake spec, for instance, since rake spec drops the test database which spec_server keeps open. Second and trickest one is reloading of the environment. Right now if > you change parts that are outside the reload mechanism of Rails, > spec_server will fail. Haven't had time to investigate into it, sorry. > I have a shell script called spec_restart, which just does a rake spec:server:stop followed by rake spec:server:start. I can't say I use it very much, though. > I use autotest, I just save the file and it's executed, then I get the > total test results without distraction, beat that ;-) > I use autotest, too (well, rspactor, which is much the same thing). But it loads the Rails environment every time it's triggered. The whole point of spec_server is that it doesn't have to do that. autotest also runs entire spec file(s). With my little script, only one spec gets run, which helps keep things narrowed down while debugging. With both autotest and spec_server running, you kind of get the best of both worlds - you can T/BDD one spec at a time very quickly but also make sure that any other potentially affected specs are run too. Before you check in, of course, you do a rake spec. ///ark
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
