Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I finally cleansed my spirit and started writing tests before code. I am hardly the New Year resolution kind of character, but I'd been meaning to do it ever since I heard about this funny methodology. I had written tests before, of course, but never systematically and I had only thought of them explicitly as being part of design when I encountered things that were difficult to test bacause they weren't designed with testing in mind. If you've ever read anything about test driven development (or Extreme Programming, which seems to feature TDD quite prominently), and certainly if you've been doing it, you'll know what I'm talking about.

I'm very, very new and don't pretend to be an expert about these things. So I'm only here for two modest contributions:

First, to encourage you to do TDD if you aren't doing it yet. It's not that hard and it's immediately rewarding.

Second, I was looking for some tips about doing it with vim and only found scattered pieces here and there. I hacked together something a little bit better than what I found so far, and am posting it here with the hope that you can use it and comment with improvements.


First of all, some organizational recommendations.

  • Put your tests in t/ and follow the convention of ##-name.t.

    Dot-t helps prove run only your tests and nothing else. Number your tests in the order that makes sense to usually test, but avoid hard interdependencies among tests and occasionally run prove --shuffle.

  • Start up vim in the base directory of the project.

    Run ctags -R here. If you use sessions, save them them here too. (Add the tags and session files to your MANIFEST.SKIP or equivalent, if you're packaging.)

  • At the top of your .t files, put this line that gives you syntax highlighting.

    # vim: ts=4 sw=4 syn=perl :

    You can put in other options, of course, but if they're global to your perl preferences then .vimrc would be a better place. Alternatively, you can say au BufRead,BufNewFile *.t setfiletype=perl in ~/.vim/ftdetect/perl_test.vim — credit Ben Prew.

Using it

The idea here is that most of the time you are working from on a particular test, and when you fix something you saw broken there, that's usually the first test you want to try again after you make your fix. So we have a notion of a "current testfile" that should be easy to set (and unset), and which should be trivial to run. If you rush off to fix a bug somewhere, you don't want to lose the current test. If a test fails, you want to jump to the compilation error if there was one, or to the definition of the failed test if there wan't. If you aren't familiar with vim's quickfix feature, read about it now.

So it's simple really. Have vim load the file below* and then you just need to know three keybindings. They all work in command mode. As a bonus, if you ,w on a code file and not on a test, a subsequent ,t will run it against perl -c to check for compilation errors.

" perltest.vim - test driven development for Perl with vim " " ,t -- Run tests " ,w -- Set current file as test file. Only this test will run. " ,W -- Unset current test file. All tests will run. " " v1.02 - Updates at function! Prove ( taint ) if ! exists("g:testfile") let g:testfile = "t/" endif if g:testfile == "t/" || g:testfile =~ "\.t$" echo system("prove -lv " . a:taint . g:testfile . " 2>&1 | +tee " . &errorfile) else echo system("perl -c -Ilib " . a:taint . g:testfile . " 2>&1 | +tee " . &errorfile) endif cfile endfunction nmap ,t :call Prove ("")<cr> nmap ,T :call Prove ("-T ")<cr> nmap ,w :let g:testfile = expand("%")<cr>:echo "testfile is now" g:t +estfile<cr> nmap ,W :unlet g:testfile<cr>:echo "testfile undefined; will run all t +ests"<cr> " based on compiler/perl.vim by Christian J. Robinson <infynity@onewes> " added formats for test failures set errorformat= \%-G%.%#had\ compilation\ errors., \%-G%.%#syntax\ OK, \%+Anot\ ok\%.%#-\ %m, \%C%.%#\(%f\ at\ line\ %l\), \%m\ at\ %f\ line\ %l., \%+A%.%#\ at\ %f\ line\ %l\\,%.%#, \%+C%.%# " FIXME make this more local. Needed for redirection syntax which isn' +t csh compatible set sh=/bin/sh " Just more convenient when shelling out a lot. set autowrite


I'll update the above with your suggestions, starting with fixing the following issues:

  1. Where to install this / how to have this loaded automatically? This should be loaded automatically when editing files with names matching \.(pl|m)|t$. Anyone remember how to do that?
    For now, I put this in ~/perltest.vim and do :so ~/perltest.vim
  2. Make it local. Currently this overwrites errorformat, which is kinda lame if you're also doing development in another language. If the effect can be localized to this file mode, all the better.
  3. ...?

See also


  • 2005-03-01T19:48Z - Added lib and taint (Thanks dragonchild). v1.02.

In reply to Test driven development with Perl and vim by gaal

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2023-02-06 12:40 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (34 votes). Check out past polls.