Faster tests with spork

[andreareginato]

Write your thoughts about the "faster tests with spork " best practice.

[myronmarston]

I'm -1 on this. Spork does extensive monkey patching that brings with it a whole host of issues. I get fast test feedback (usually under a second between saving the file and seeing red/green) without using spork and bringing in the baggage that it involves. Spork is a band aid on a problem that is better solved through better design, and being intentional about only loading the dependencies that you need.

[nikhilkrishna]

I think Zeus (https://github.com/burke/zeus) is a better solution than Spork. It automatically detects and reloads whenever there are any changes to the rails solution it is monitoring and you can leverage it to run all your rake tasks, console, etc faster...

[andyw8]

+1 for Zeus

@myronmarston I agree with that for unit tests, but a (full-stack) Rails integration test will never run in < 1s

[mvz]

I'm currently using spin combined with kicker for this. It works without the need for a patched Ruby, and without any configuration.

[andreareginato]

I agree with @myronmarston about the fact that Spork does extensive monkey patching that brings to lot of issues, but if you are able to fine tune it, it will change your way about testing.

I think everyone testing a rails app agree on the fact that waiting (in the most optimistic cases) 5+ sec will break your flow.

Here is how I do. I've the Guardfile that reloads Spork if some "preloaded files" are changed. In the same Guardfile I run a specific test when the test or the relative class is upated. All fo this in 1 sec and I'm happy with that because I can focus on coding.

@nikhilkrishna, I didn't knwo Zeus. It looks awesome and way better than spork, mainly when there is something wrong. I still can't find enough documentation. Do you have some links that could make clean up my mind?

[nikhilkrishna]

Well if the vimeo screencast (http://vimeo.com/46795747) on the main Readme is not enough and you prefer good old man style documentation - a good place to start would be to type $ zeus help wherever you have installed the zeus gem... It brings up a nice man page which provides pretty clear descriptions as to what zeus is and how to set it up in a Rails application. It also provides some interesting links to the relevant documentation in Github.

There is a pretty good technical overview with a nice and simple architecture diagram at - https://github.com/burke/zeus/blob/master/docs/overview.md . One of the interesting things I learnt here is that the core Zeus library is actually written in Go (http://golang.org/)

If you want to learn about how zeus detects and customizes itself with regard to the Rails application, have a look at - https://github.com/burke/zeus/blob/master/docs/ruby/modifying.md

A sample zeus.json file is given at - https://github.com/burke/zeus/blob/master/examples/zeus.json .

[Spaceghost]

See issue #16 and my comment for a short summary of my opinion.

These other tools sound nifty, but I think I like the spin+kicker combo better. 👍

[pepe]

@nikhilkrishna do you know if zeus is usable for other things than Rails (padrino, sinatra). It looks it is Rails only.

[kossnocorp]

👍 for zeus.

[therealadam]

-1 for spork, Zeus, et. al.

I don't think any kind of framework pre-loading tools should be recommended. They can lead to hours wasted due to debugging the tool instead of working on the app, at best. They are black magic, at worst.

Rather, every individual developer should decide whether they want to make a preloading tool part of their workflow. From there, a team working on an RSpec project should make sure that they don't make any changes that prevent the tool from working. Most importantly, any particular workflow, including a preloading tool or not, should not be enforced by the code that is committed for the project.

[pepe]

+1 @therealadam actually it could be much more general advice.

Maybe unless some dev want to use Windows?

[andreareginato]

I'm struggling on this point. I think that a test suite built on top of rails requires a preloading system. Probably Spork is the worst, but it saves a lot of time. I think I'll be adding an introduction where I describe the @myronmarston point and then add the Zeus and Spin links describing why they are better than Spork.

If someone would put a working configuration using Zeus or Spin I'll be more than happy to change the Spork one.
Any correction and comment to the updated guideline is appreciated.

[mvz]

For running Spin, I have two terminals, one running spin serve, the other running kicker -r rails -b "spin push". No configuration is needed.

I automated setting up the two terminals in a tmux session with tmuxinator, but that is not needed per se.

[ck3g]

+1 for zeus

[brendanstennett]

+1 for zeus

To set it up with guard:

# Gemfile
gem 'zeus', group: :test

# Guardfile
guard :rspec, zeus: true, bundler: false do # (instead of "guard :rspec do" for this line)
  # ..
end

Then just run zeus start in one console and guard in another. There is a guard-zeus gem to automatically start and stop zeus with guard, but I haven't had much luck with it