|Do you know where your variables are?
Test driven development with Perl and vimby gaal (Parson)
|on Feb 26, 2005 at 17:17 UTC
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.
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.
I'll update the above with your suggestions, starting with fixing the following issues: