12

I'm using cucumber, rails3, rspec2 and autotest. I'm trying to figure out why my features are infinitely looping. I suspect it some file being changed during the tests but I'm not sure which one. I've added some exceptions to my .autotest with no dice.

Are there any steps I can take to troubleshoot this problem?

It'd be cool if I could see what files are triggering a rerun or, at run time, what files are being watched/not watched.

here's my .autotest contents

require 'autotest/growl'

Autotest::Growl::clear_terminal = false

# Skip some paths
Autotest.add_hook :initialize do |autotest|
    %w{.git .DS_store db log tmp rerun.txt}.each { |e| autotest.add_exception(e) }
end
Dane O'Connor
  • 75,180
  • 37
  • 119
  • 173

6 Answers6

15

Ok, so I figured it out. I dove into autotest's source to get a better understanding of what was going on. It creates a Regexp.union out of all the exceptions and ignores files who's relative paths match the complied expression.

To better understand the bug I added everything in my project's directory to .autotest except ./app, ./lib, ./public, ./script, ./spec and ./features. Something like this:

# .autotest - to troubleshoot
Autotest.add_hook :initialize do |at|
  at.add_exception(%r{^\./\.git})
  ...
  at.add_exception(%r{^\./db})
  ...
  at.add_exception(%r{^\./rerun.txt})
  ...
end

When I did this I didn't get an infinite loop. After that I just began to comment out each exception. Turns out, the only file I had to manually ignore was Gemfile.lock. For some reason this is either being changed or confusing autotest to the point where it makes cucumber loop.

Thus, this .autotest solved the problem:

# .autotest - to fix
Autotest.add_hook :initialize do |at|
  # Gemfile.lock is causing cucumber to run infinitely. Don't watch it.
  at.add_exception(%r{^\./Gemfile.lock})
end

I'm going to report on the cucumber list to let them know they should add that to the built in autotest exceptions.

Dane O'Connor
  • 75,180
  • 37
  • 119
  • 173
  • 3
    I tried excepting on just Gemfile.lock but that didn't do the trick. I ended up using the following: Autotest.add_hook :initialize do |at| %w{.svn .hg .git vendor rerun.txti db log tmp .DS_store Gemfile.lock}.each {|exception| at.add_exception(exception)} end – localshred Dec 01 '10 at 20:44
  • Telling autotest to ignore `Gemfile.lock` worked for me. It looked like while running my specs, `Gemfile.lock` was being altered (my `gem 'capistrano'` line's dependencies were being altered during the test, and then put back afterward... weird). – Dylan Markow Mar 16 '11 at 16:35
  • Thank you, thank you, thank you. My only regret is that I have but one upvote to give to this answer. – bradheintz Jul 20 '11 at 00:40
7

Just wanted to say thanks. Turns out, for me, it was the log directory. My .autotest file looks like this.

# .autotest
Autotest.add_hook :initialize do |at|
  # Log directory is causing cucumber to run infinitely.
  at.add_exception(%r{^\./log})
end

For reference, see "Customizing Autotest Behavior" in http://github.com/aslakhellesoy/cucumber/wiki/Autotest-Integration, which talks about the infinite loop problem.

Harry Love
  • 1,920
  • 1
  • 25
  • 25
6

In Linux/Unix you can use the command:

$ find . -mmin -5

to figure out which files were modified in the last 5 minutes (or whatever lapse is appropiate). This can greatly help in finding the file which is triggering infinite loop. Then add the exception as explained in the other answers.

In my case, the culprit was webrat.log.

Gustavo Giráldez
  • 2,610
  • 18
  • 12
5

It's worth noting that you can pass -v to autospec/autotest and it will print out what triggered it to run.

Jared
  • 2,885
  • 2
  • 28
  • 31
1

Put your files under version control. Run autotest and then run your VC system's status command (e.g. git status) to see what changed.

PS: It's probably rerun.txt, which is touched by Cucumber whenever you run features.

zetetic
  • 47,184
  • 10
  • 111
  • 119
  • using git. The status reports that nothing has changed (I'm probably ignoring the file that gets changed, _if_ there is one). I've also added rerun.txt to my autotest exceptions. Updated answer to include my .autotest content. – Dane O'Connor Jul 06 '10 at 22:23
  • Interesting idea though, I'll try a fresh checkout and track everything soon to see if that helps. – Dane O'Connor Jul 06 '10 at 22:25
  • 2 files being modified (according to git) are db/test.sqlite3 and log/test.log. Seems like .autotest should be telling autotest not to watch them. I'm sure cucumber-rails has this built in as well. Does my .autotest look off? – Dane O'Connor Jul 06 '10 at 22:45
  • No, your `.autotest` looks right to me. Maybe it's not due to a changed file after all... One possible clue -- I have `vendor` excluded, though I can't remember why. I do recall going through the same problem as you, with autospec looping forever, and it was due to a watched file being changed, but I don't remember which one(s). – zetetic Jul 07 '10 at 00:20
  • thanks for the sanity check and direction here. I've posted how I eventually solved the problem in my answer. +1 for the help. – Dane O'Connor Jul 08 '10 at 16:32
0

You can use ruby-debug . You can then add debugger statements in your code and break on them .

jmhowwala
  • 49
  • 4
  • Ok I can handle that, but once I break how can I inspect Autotest? I'm not sure where to look in order to peak into it's internals and see why it's doing what it's doing. – Dane O'Connor Jul 06 '10 at 21:10