Flylib.com

Books Software

 
 
 

Hack 10. Run Tests from Within Vim


Hack 10. Run Tests from Within Vim

Run your tests from your editor.

One of the nice things about Perl is the "tweak, run, tweak, run" development cycle. There's no separate compile phase to slow you down. However, you likely find yourself frequently writing tests and madly switching back and forth between the tests and the code. When you run the tests, you may exit the editor or type something like !perl -Ilib/ t/test_program.t in vi's command mode. This breaks the "tweak, run" rhythm.

The Hack

Perl programmers don't like to slow things down. Instead, consider binding keys in your editor to the chicken-bone voodoo you use to run your test suite.

Binding keys

By running the tests from within the editor, you no longer have to remember how to execute the tests or edit the editor. Just tweak and run. Add the following line to your .vimrc file to run the currently edited test file by typing ,t (comma, tee):

map ,t  <Esc>:!prove -vl %<CR>

This technique uses the prove program to run your tests. prove is a handy little program distributed with and designed to run your tests through Test::Harness . The switches are v (vee), which tells prove to run in "verbose" mode and show all of the test output, and l (ell), which tells prove to add lib/ to @INC .

If lib/ is not where you typically do your development, use the I switch to add a different path to @INC .

map ,t  <Esc>:!prove -Iwork/ -v %<CR>

Seeing failures

If it's a long test and you get a few failures, it can be difficult to see where the failures were. If that's the case, use ,T (comma capital tee) to pipe the results through your favorite pager.

map ,T  <Esc>:!prove -lv % \ less<CR>

Of course, make sure your editor does not have those keys already mapped to something else. This hack does not recommend breaking existing mappings in your editor.


Managing paths

These techniques do tend to require that you edit your tests in the "standard" way. If you have your tests organized in subdirectories, switching to the t/customer/ directory and editing save.t may cause problems when trying to tell prove which directories to use. If you habitually do this, don't tell prove which paths to add to @INC .

map ,t  <Esc>:!prove -v %<CR>

Instead, have your tests add paths to @INC :

use lib '../../lib';

That can get a bit clumsy and it can make it rather tough to reorganize your tests, but it works.

Here's a little alisp for Emacs users to put into your ~/.emacs file to get the same thing. It binds to C-c t , but you can change to whatever you prefer:

(eval-after-load "cperl-mode"
    '(add-hook 'cperl-mode-hook
       (lambda () (local-set-key "\C-ct" 'cperl-prove))))
  (defun cperl-prove ()
    "Run the current test."
    (interactive)
    (shell-command (concat "prove -v "
      (shell-quote-argument (buffer-file-name)))))




Hack 11. Run Perl from Emacs

Make Perl and Elisp play nicely together.

Emacs's long and varied history happens to embody much of Perl's "There's More Than One Way To Do It" approach to things. This is especially evident when you run a small bit of Perl code from within Emacs. Here's how to do just that.

The Hack

Suppose you really need to know the higher bits of the current value of time( ) . In Perl, that's print time() 8>>; . You could use the shell-command command (normally on Control-Alt-One), and enter:

perl -e 'print time( ) >> 8;'

Emacs will dutifully run that command line and then show the output. Note though that you have to remember to quote and/or backslash-escape the Perl expression according to the rules of your default shell. This quickly becomes maddening if the expression itself contains quotes and/or backslashes or even is several lines long.

An alternative is to start an "Emacs shell" in an Emacs subwindow, then start the Perl debugger in that shell. That is, type alt-x " shell " Enter, and then perl -de1 Enter, and then enter the expression just as if you were running the debugger in a normal terminal window:

%

perl -de1

Loading DB routines from perl5db.pl version 1.27
Editor support available.

Enter h or \Qh h' for help, or \Qman perldebug' for more help.

main::(-e:1):    1
  DB<1>

p time( ) >> 8

4448317
  DB<2>

This means you don't have to escape the Perl expression as you would if you were sending it through a command line, but it does require you to know at least a bit about the Perl debugger and the Emacs shell. It also becomes troublesome in its own way when your expression is several lines long.

A simpler alternative is to save your snippet to a file named delme123.pl and to run that via a command line, but this is a very effective way to fill every directory in reach with files named with the same variant of delme .

I prefer defining a new function just for running Perl code in the Region (what you have selected in Emacs, between the Point and the Mark):

(defun perl-eval (beg end)
  "Run selected region as Perl code"
  (interactive "r")
  (shell-command-on-region beg end "perl")
   ; feeds the region to perl on STDIN
)

I bind it to my CTRL-Alt-p key:

(global-set-key "\M-\C-p" 'perl-eval)

Then when I want to run some Perl expression in whatever buffer I happen to be in, I just set the mark, type the expression, and hit CTRL-Alt-p. It requires no special escaping, nor are there any problems when the Perl code spans several lines.