13

Does anyone have any concrete reasoning for using one autotesting runner over another? I've used both Autofeature+autotest, I really like the built-in process that this sets up in that it runs my rspec unit tests first, and then the cucumber tests, and only the last failing test - it lends itself to the standard workflow of writing the cucumber tests, setting up the steps until they fail and then dropping down into unit tests for the detailed functionality.

I've used guard in the standard rspec configuration and it's worked well also, but I didn't fold in the cucumber tests - didn't have time to experiment further.

Just wondering if anyone has any specific reasons for using one over another, or whether one way mitigates a weakness of the other.

Thanks for the input, Tony

Tonys
  • 3,349
  • 4
  • 24
  • 27

2 Answers2

24

I recently moved from autotest to guard for a reason, it works better than autotest and it has a lot of available guards. So with a single process you can monitor a lot of things.

Currently I use it for Rspec, Passenger, and Yard but the list is very long and you can always implement your guard if you need it for something else.

I find it very useful especially for passenger when developing because it will reload the server as soon as you change something which need the server restarted (i.e. routes, config, etc).

Some of the available guards can be replaced in some way, for example with yard you can launch it's own server, but then you need two different process, with guard you can do all the work with a single process.

In other words Guard is more a generic Framework for every process which needs to do something triggered by a file change, autotest is restricted to running tests.

Update

In response to your comment

You can randomize spec order by using --rand in your .rspec file if you have Rspec > 2.8. In this way that is achieved at rspec order and it works also when you call rspec with rake or with rspec executable.

For less files there is guard-less.

Moreover latest versions of guard also embed a Rails console with pry available when guard is idle, very useful in development mode.

Community
  • 1
  • 1
Fabio
  • 18,856
  • 9
  • 82
  • 114
  • Thanks for the input. I actually still use guard to run livereload once I've implemented a page and start working on the design and element placements. When using guard to run the specs, does it randomize the test order the same way autotest does? I'll need to look into the guard files when I have less projects on the go to see if I can fold it confidently into that part of my process. – Tonys Aug 29 '11 at 22:29
  • @Tonys I've updated my answer. BTW, accept it if it's useful ;-) – Fabio Nov 19 '12 at 13:45
-1

Minitest, spork and guard don't work together. LoadError: no such file to load -- -r

Because of this: https://github.com/semaperepelitsa/spork-minitest/issues/2

So I switched to autotest (see the Lightweight test suite by Michael Grosser in the README). Fsevent seems to reduce CPU load but it's not as 'reactive' as my old Guard setup with fsevent. I'm not sure why.

Update: actually I am sure why. I opened a (minor) issue on autotest: https://github.com/grosser/autotest/issues/33

It's the sleep default of 1 second. I have a workaround on the issue but it's a hack. Don't know an elegant solution. With that in place, it behaves as quick as Guard and works with Minitest.

Autotest+Minitest doesn't seem to be able to do colorized output because it's not a tty. This isn't related to Autotest iirc. I like the Guardfile setup of Guard, I don't know where the 'watchers' are in Autotest. So far, it just works but this may be an issue.

squarism
  • 3,242
  • 4
  • 26
  • 35
  • 1
    use ` gem 'guard-minitest', :git => 'git://github.com/pmq20/guard-minitest.git'`, this one works with the combination. – Minqi Pan Nov 16 '12 at 07:58