Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faster tests with spork #17

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

Faster tests with spork #17

andreareginato opened this issue Oct 3, 2012 · 27 comments
Labels

Comments

@andreareginato
Copy link
Collaborator

@andreareginato andreareginato commented Oct 3, 2012

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

@myronmarston
Copy link

@myronmarston myronmarston commented Oct 3, 2012

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
Copy link

@nikhilkrishna nikhilkrishna commented Oct 4, 2012

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
Copy link

@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
Copy link

@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
Copy link
Collaborator Author

@andreareginato andreareginato commented Oct 6, 2012

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
Copy link

@nikhilkrishna nikhilkrishna commented Oct 7, 2012

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
Copy link

@Spaceghost Spaceghost commented Oct 13, 2012

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
Copy link

@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
Copy link

@kossnocorp kossnocorp commented Oct 15, 2012

👍 for zeus.

@therealadam
Copy link

@therealadam therealadam commented Oct 22, 2012

-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
Copy link

@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
Copy link
Collaborator Author

@andreareginato andreareginato commented Mar 9, 2013

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
Copy link

@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
Copy link

@ck3g ck3g commented Mar 21, 2013

+1 for zeus

@brendanstennett
Copy link

@brendanstennett brendanstennett commented Jun 19, 2013

+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
Copy link
Collaborator Author

@andreareginato andreareginato commented Jun 22, 2013

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

@mvz
Copy link

@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
Copy link

@alexandru-calinoiu alexandru-calinoiu commented Jun 22, 2013

-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
Copy link

@Spaceghost Spaceghost commented Jun 22, 2013

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
Copy link
Contributor

@onebree 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
Copy link

@orbanbotond orbanbotond commented May 5, 2015

+1 spring

@onebree
Copy link
Contributor

@onebree 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
Copy link

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

@jmromer
Copy link

@jmromer jmromer commented Jun 1, 2015

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

@onebree
Copy link
Contributor

@onebree 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
Copy link
Collaborator Author

@andreareginato andreareginato commented Jun 2, 2015

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
Copy link
Contributor

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

pirj added a commit to rubocop/rspec-style-guide that referenced this issue Nov 2, 2018
Original links:
http://www.betterspecs.org/#spork
http://lelylan.github.io/betterspecs/#faster
Discussion: betterspecs/betterspecs#17
https://github.com/lelylan/betterspecs/blob/gh-pages/index.html#L844

https://github.com/jstorimer/spin and https://github.com/sporkrb/spork
mentioned in the original recommendation are long (since circa 2014)
unmaintained, so it doesn't make much sense to drag them through.
Spring became the de-facto standard for Rails.
pirj added a commit to rubocop/rspec-style-guide that referenced this issue Nov 7, 2018
Original links:
http://www.betterspecs.org/#spork
http://lelylan.github.io/betterspecs/#faster
Discussion: betterspecs/betterspecs#17
https://github.com/lelylan/betterspecs/blob/gh-pages/index.html#L844

https://github.com/jstorimer/spin and https://github.com/sporkrb/spork
mentioned in the original recommendation are long (since circa 2014)
unmaintained, so it doesn't make much sense to drag them through.
Spring became the de-facto standard for Rails.
pirj added a commit to rubocop/rspec-style-guide that referenced this issue Nov 7, 2018
Original links:
http://www.betterspecs.org/#spork
http://lelylan.github.io/betterspecs/#faster
Discussion: betterspecs/betterspecs#17
https://github.com/lelylan/betterspecs/blob/gh-pages/index.html#L844

https://github.com/jstorimer/spin and https://github.com/sporkrb/spork
mentioned in the original recommendation are long (since circa 2014)
unmaintained, so it doesn't make much sense to drag them through.
Spring became the de-facto standard for Rails.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet