How do I make Karma's auto-watch feature pause before running tests?

Question

I'm running into what I think is a race condition between Vim saving files and Karma re-running my Jasmine unit tests. Here's a sequence of four test runs which demonstrates the symptom (I truncated the extremely long paths in the error log):

$ karma start karma.conf.js --auto-watch
[... snip a lot of coding and test running ...]
PhantomJS 1.6 (Linux) LOG: 'Running tests at 2013-08-14T08:19:57.252Z'
PhantomJS 1.6 (Linux): Executed 4 of 4 SUCCESS (0.307 secs / 0.013 secs)
PhantomJS 1.6 (Linux) LOG: 'Running tests at 2013-08-14T08:20:09.866Z'
PhantomJS 1.6 (Linux): Executed 4 of 4 SUCCESS (0.288 secs / 0.012 secs)
PhantomJS 1.6 (Linux) LOG: 'Running tests at 2013-08-14T08:20:14.366Z'
PhantomJS 1.6 (Linux) controller should have a breadcrumb after $routeChangeSuccess FAILED
        Error: No module: myapp.question
            at /home/rmunn/.../angular.js:1124
            at ensure (/home/rmunn/.../angular.js:1065)
            at module (/home/rmunn/.../angular.js:1296)
            at /home/rmunn/.../angular.js:2806
        TypeError: 'undefined' is not an object (evaluating 'rootScope.$broadcast')
            at /home/rmunn/.../unit/controllersSpec.js:35
PhantomJS 1.6 (Linux): Executed 4 of 4 (1 FAILED) (0.312 secs / 0.014 secs)
PhantomJS 1.6 (Linux) LOG: 'Running tests at 2013-08-14T08:20:28.588Z'
PhantomJS 1.6 (Linux): Executed 4 of 4 SUCCESS (0.287 secs / 0.013 secs)

The only change I made to trigger these four runs was adding and removing whitespace from the question.js file; there were no substantial code changes, but run #3 failed where runs 1, 2, and 4 succeeded.

My Vim configuration is set up to keep backup files, and by default Vim keeps backup files by renaming the original file and writing a new one. (Except under certain conditions, which don't apply here). What I think is going on is that I'm triggering a race condition: Vim renames question.js (or whatever file I just edited), Karma detects that change and starts running tests, and because I have so few tests right now, the tests all run before the Linux process scheduler hands control back to Vim. Once Vim gets scheduled again, it writes the new contents of question.js, but by that point it's too late for the Jasmine test that depended on question.js existing and being non-empty.

I could possibly fix this by configuring Vim not to keep backup files, but I'd really rather not run that risk. There's a reason I use backup files, after all. So is there a way to tell Karma "when you detect a file change, pause for N milliseconds, then run the unit tests"? While it would be a brute-force solution, it would solve this particular race condition. Or if anyone has other clever ideas to offer, I'd love to hear those too.

Answer 1

This GitHub issue discusses this issue as well. Vim can be configured to make backups by copying and then overwriting the original, instead of moving the original and writing a new file. While this isn't technically an answer to your question, it should be enough to solve your problem:

set backupcopy=yes

Vim will now edit the file in place, and Karma will detect this as "changed" instead of "removed".

See :help 'backupcopy' for details:

                        *'backupcopy'* *'bkc'*
'backupcopy' 'bkc'  string  (Vi default for Unix: "yes", otherwise: "auto")
            global
            {not in Vi}
    When writing a file and a backup is made, this option tells how it's
    done.  This is a comma separated list of words.

    The main values are:
    "yes"   make a copy of the file and overwrite the original one
    "no"    rename the file and write a new one
    "auto"  one of the previous, what works best

Answer 2

From the karma documentation, it seems there is an "exclude" option to remove some file pattern. If you modify your option to have a different name for backup and ignore Vim backup format, it should work properly.

But it will change your workflow somehow, you'll probably have to ignore the backup in your .gitignore as well.

Just a comment aside, I feel like with vim persistent undo (version >7.3), it seems that the backup file is a bit redundant. So maybe use,

set nobackup

set undodir=~/.vim/undodir
if (v:version >= 703)
   set undofile
   set undolevels=1000 "maximum number of changes that can be undone
   set undoreload=10000 "maximum number lines to save for undo on a buffer reload
endif