Faster tests with spork #17

Open
andreareginato opened this Issue Oct 3, 2012 · 27 comments

Projects

None yet
@andreareginato
Collaborator

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
andyw8 commented Oct 4, 2012

+1 for Zeus

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

@mvz
mvz commented Oct 5, 2012

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

@andreareginato
Collaborator

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
pepe commented Oct 15, 2012

@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
pepe commented Oct 23, 2012

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

Maybe unless some dev want to use Windows?

@andreareginato
Collaborator

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
mvz commented Mar 11, 2013

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
ck3g commented Mar 21, 2013

+1 for zeus

@HuffMoody

+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
Collaborator

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

@mvz
mvz commented Jun 22, 2013

-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
Contributor
onebree commented Mar 26, 2015

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
Contributor
onebree commented May 5, 2015

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
andyw8 commented May 5, 2015

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.

@jkrmr
jkrmr commented Jun 1, 2015

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

@onebree
Contributor
onebree commented Jun 1, 2015

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
Collaborator

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
Contributor
onebree commented Jun 2, 2015

@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. 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment