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

[andreareginato]

@HuffMoody Would you love to update the guideline with a working example related on zeus so that we can remove spork?

[mvz]

-1 for Zeus.

I'm not using it myself, but I've seen my colleagues have no end of trouble with Zeus. Half the time they want to show me some failing test, I first need to wait for Zeus to restart because it either crashed or didn't reload the right code.

[alexandru-calinoiu]

-1 for Zeus,

I was not able to use it in a ruby 2.0 / rails 4.0 project, it simply hanged with no output.

[Spaceghost]

If we are truly aiming for betterspecs, then I think your test suite should be broken up into unit tests and at least functional+integration suites. The unit tests shouldn't need rails loaded and they should be extremely fast to run so that you have no use for something like spork or zeus.

For your heavier tests, like your functional or integration, I typically run them less often and never automatically. But if the 30+ seconds to load rails and whats likely an ungodly amount of gems in your Gemfile is too painful, perhaps you might enjoy one of those preloaders.

On a slightly less generally helpful note, if you've got a big ol' suite of tests in rails then I'm pleased to inform you that you're probably not being as awesome as you could be. At work, as well as in my recent projects, rails is just a web delivery mechanism whose test suite test web-specific behaviours rather than my business logic and things I pull out into services.

My models are typically extremely light, along with controllers. This is the best way I have ever used rails, and it's so much more consistently fun, easy to change, and doesn't resist refactoring as much while the project goes forward. In my opinion, this is what sustainable rails looks like.

[onebree]

From what I can tell (from issue submissions and forum posts), Spork does not support RSpec3/Rails4 (not sure if both or just one). I received an error that would simply waste time to monkey patch. Instead, I use Spring -- packaged with Rails >=4.1

[orbanbotond]

+1 spring

[onebree]

I am all up making a PR for recommended Spork for Rails3/RSpec2 projects, and Spring for Rails4/RSpec3.

I understand that Zeus is a favorite for some, but I think Spring is a better candidate for this guide, since it is a gem authored by the Rails org on github, and packaged with current versions. It requires little configuration, if at all -- only after_forks similar to Spork.

[andyw8]

This issue was opened over two and half years ago, things have changed a lot over that time.

I don't think it's worth trying to document best practices for legacy versions of Rails or RSpec.

As I see it, the current basic guidance just needs to be to use Spring via spring-commands-rspec.

[jmromer]

+1 for pointing to spring-commands-rspec instead of documenting best practices for legacy versions

[onebree]

Does anyone know if the repo is being maintained anymore? Like, for being about rspec (ruby), it should utilize Jekyll and Github Pages. Then we could read the articles in Markdown.

Anyway, I'd like to help, if possible. @andreareginato can I become a collaborator to help relieve the issues/PRs?

[andreareginato]

Hi @onebree. Thanks a lot for writing about possible collaboration. I'm not dedicating much time on the project and I would love to involve some people taking good care of it. Github pages sounds great to me as usable tech stack. For this point, we simply need to start making the job making the infrastructure more simple to handle. About the issues/PR help, sounds great to me. Before, I would love to know you little better, maybe with a skype call or a simple mail where you describe what you do in life.

I'm also open on moving to spring for tests. PR will be accepted.

[onebree]

@andreareginato I do not have skype, but I do have Twitter and Google Hangouts. Unfortunately, I do not have time tonight for a video chat. I will email you (look for my username) at the address listed on your Github. Ask me any questions you have. 😀