search

netzpirat / guard-rspectacle

Experimental embedded RSpec runner.
MIT License
37 stars 5 forks source link

[Suggest] Explain philosophical differences w/Spork #4

Closed jaylevitt closed 12 years ago

jaylevitt commented 12 years ago

We can do what guard-rspectacle does with Spork, so there must be some limitation or itch that spurred you to write guard-rspectacle. Could you say a little about that in the README?

netzpirat commented 12 years ago

Good point. I'll add some information about the philosophy, current status and future plans next week.

netzpirat commented 12 years ago

Sorry for ignoring you so long. I'm currently not actively developing guard-rspectacle, mainly because I do only frontend code at the moment. I will continue when I have work to do at the backend again.

To answer your question:

I never liked Spork, it's a constant source for issues in guard-rspec, many people don't get the setup right. It's not properly maintained and has a lot of open issues and pull requests. I don't like that.

Since Spork runs in another process, there are some strange hacks needed to provide Guard notifications. Running the whole test suite takes more time than without Spork, due the drb protocol overhead. So in a typical BDD cycle, it slows down the "test all on start", but speeds up single specs. This is not optimal.

Also I've had some issues with JRuby. Sometimes it works, sometime not.

All these has lead to the idea of guard-rspectacle. It's currently far away from being optimal and has it's downsides, as described in the README. I'll add a fork approach in the future, which will solve some of the problems, but this will be not in the next week or even months.