Add Tester option for rspec/cucumber
dhh opened this issue · 11 comments
I shudder at the thought, but given it's popularity, I guess we should. @nviennot did some work on this for rspec-console that can serve as prior art: https://github.com/nviennot/rspec-console/blob/master/lib/rspec-console/runner.rb
Maybe it doesn't need to be so convoluted. I didn't consider forking the process. I wonder what is the performance hit to fork+load all the initialization code of the test suite though.
I doubt it's that much. I'd rather go down this path for a bit and see if we can keep things simple for as long as possible.
On Dec 22, 2012, at 2:03 PM, Nicolas Viennot notifications@github.com wrote:
Maybe it doesn't need to be so convoluted. I didn't consider forking the process. I wonder what is the performance hit to fork+load all the initialization code of the test suite though.
—
Reply to this email directly or view it on GitHub.
That's fair.
You can also reduce substantially the overhead by performing the Bundler.require before the fork. Since the vast majority are not Rails.env sensitive, it's safe to load them while in the dev environment.
A few caveats from forking though:
- Loading capybara with headless webkit / selenium will have to be done over and over. Preloading in the dev environment might be difficult since it probably won't survive a fork.
- Threads are not preserved. It's probably okay in most cases, and maybe even beneficial, but it's something to be aware of.
Yeah, sounds reasonable to preload the test dependencies in dev for the console. So what to do about the capybara thing? Are you seeing that just requiring it sets up a bunch of stuff before you start interacting with the classes? Why wouldn't all that stuff not be setup after the fork?
On Dec 22, 2012, at 2:23 PM, Nicolas Viennot notifications@github.com wrote:
That's fair.
You can also reduce substantially the overhead by performing the Bundler.require before the fork. Since the vast majority are not Rails.env sensitive, it's safe to load them while in the dev environment.
A few caveats from forking though:
• Loading capybara with headless webkit / selenium will have to be done over and over. Preloading in the dev environment might be difficult since it probably won't survive a fork.
• Threads are not preserved. It's probably okay in most cases, and maybe even beneficial, but it's something to be aware of.
—
Reply to this email directly or view it on GitHub.
Actually, everything is done after the fork, which is a problem for performance. I haven't measured the hit of having to launch Xvfb+webkit_server or firefox all the time but I assumed the slowness of spork came from forking since it doesn't allow any state caching to operate.
Also JRuby doesn't fork.
Re: rspec, I'm thinking we can just have a "spec" command that works the same. No need to overload "test".
In your question, you are using "this", and I don't know what it refers to. So I'll try to answer something.
Forking does not work with JRuby.
https://github.com/nviennot/rspec-console does not use fork.
@nviennot the "this" was implying "this issue", meaning adding rspec support to the commands gem (sorry for the confusion). I knew JRuby didn't support fork (which is why I was asking if adding rspec support might work without fork) but after looking I saw commands uses it already, so it would seem to make sense to do something similar for rspec support.
Enabling JRuby support would certainly add more complexity to this gem than it's currently worth, unless a bunch of JRuby people come asking commands to support it :)
Thanks for your quick response.
You might want to use https://github.com/nviennot/irb-config which also includes the commands gem, and adds supports for rspec/cucumber with a heavy weight mechanism.
I'm not sure how I can help you with vanilla commands. Sorry.
In my fork I add simple function to detect if project use rspec.
https://github.com/grzlus/commands
Maybe I should create spec function, but difference between test and spec are very small.