I’m the core developer for Puppet, and I’ve currently got 172 spec files, with a total of about 23k lines of code (I’ve still got a lot of legacy test/unit code).

According to two important but qualitative tests, autotest was taking a lot of my machine’s energy. First, when it was running, the fan *never* stopped, and second, the MenuMeters graph in my menubar was always at around 25% cpu.

I’d recently taken to hitting ^z when not actively programming, since it was making my computer so much hotter, louder, and generally more annoying.

I’ve switched in this code and now my machine once again is behaving like I’m not playing a video all the time.

So, Ryan: I’d say autotest in its current form works fine for smaller projects or maybe if you’re interested in waiting longer for tests to trigger, but it’s pretty clear that events are a better way to handle this than polling, in the general case but especially for larger projects. Most platforms support some kind of polling interface — Linux has had FAM-like daemons for years, and now OS X has a good one too. I think this bit of autotest should be abstracted out so it can be made to support whatever events system exists locally, with a fall-back to using polling when necessary.

Here’s the solution: http://blog.netphase.com/2008/01/05/autotest-cpu-fix/

When a test fails it’s file and failure message are placed in @files_to_test. I believe this is how autotest remembers what tests failed before so it can just rerun that failed test if any changes occurred that are nonspecific to any tests. Now a few of my tests create files while running and then delete the files when the test is over. The deletion of these files triggers an FSEvent. run_tests_in_paths is called from the callback and no files are found. So ideally it should stop right here. But remember that our friend @files_to_test still has the last failed test in it so run_tests_in_paths keeps running and reruns our test again, and again, and again….

To fix this problem I made a few changes that allow FSEvent to ignore certain files based on a project by project specification. First I hooked into initialize and added a class level variable to stash our ignore pattern into (~/.autotest):

Autotest.add_hook :initialize do |i|
@@fsevent_ignore_pattern = nil
end

I modified the call back like so (~/.autotest):

callback = proc do |stream, ctx, numEvents, paths, marks, eventIDs|
paths.regard_as(’*')
rpaths = []

numEvents.times { |i| rpaths < 0
end

What this does is converts the file paths taken from the FSEvent, converts them to relative paths (i.e. ./spec/models/blog_spec.rb) and then filters them through @@fsevent_ignore_pattern. I setup the setting of @@fsevent_ignore_pattern as a hook so it can be specified on a project by project basis. So in my project directory autotest file (rails_app/.autotest):

Autotest.add_hook :set_fsevent_ignore_pattern do |i|
@@fsevent_ignore_pattern = /^\.\/(?:spec\/test_data|log\/)/
end

I should also mention one last thing that I did: Since the paths from FSEvents are now converted to relative @exceptions now works as it should (before the paths were coming in absolute and the regexp was failing all the time). In find_files_in_paths I swapped out the line:

filename = f[current_dir..-1]

for:

filename = f.sub(/^\.\//, ”)

So I realize that this is a huge amount of reading, but I hope someone finds it helpful. It’s a basically a hack on top of a hack. I’m going to try and write a plugin for autotest that handles this much cleaner in the future.

and thanks to Ryan for the tip on running autotest in verbose to get the file changes (apologies to Ryan: I said I had my .autotest disabled, but I guess I was wrong, however I also said it was most likely my fault

rescue LoadError => e
puts “Failed to use FSEvents instead of polling files”
end

Only recently and only on one project have I noticed the problem Tammer’s talking about. I’m not sure what it is and haven’t bothered to investigate yet.

You’re all doing rails development with a stuffed-to-the-gills vendor/ aren’t you? Ever think of excluding the vendor directory?

Next version of autotest will make doing that a lot cleaner… coming soon.

aizatto, thanks for sharing the code. Now I can use autotest on flights.

Is there anything wrong with targeting a certain platform? If you are working on OS X, then one should be happy that because you are on this platform you can use this feature, whilst working on the other ones, you don’t really have much choice. Just pros and cons of the platforms one uses. Does it take away from the functionality of autotest? No.

Yes, you can put it to sleep for a while, but I still find it unnecessary to traverse the directory tree again if you don’t really need to.

P.S. alias the method and you won’t get that warning.