All the Perl that's Practical to Extract and Report

Making testing life easier in vim

Ovid on 2004-12-07T17:44:22

Now that I've returned to a "normal" development environment, I've found that I miss many of the tools that were available in my previous place of employment. Three of the most useful are represented by the following vim mappings.

map ,t :!prove -lv %
map ,T :!prove -lv % \| less
map ,d :!perl -d -Ilib/ %

I think, perhaps, I should start a project to build custom vim tools to make standard Perl testing easier. I miss many of the things I had, but we had a vary standardized development environment. Right now, my tools work only because I ensure that I fire up vim from the proper directory. That's an awful limitation.

I particularly miss the tool that allowed us to be dumped directly into the debugger at a given test. Maybe Test::Harness should offer support for this which prove can exploit? (Though I'm not sure if Test::Harness is the best place for this.)

color me interested...

WebDragon on 2004-12-07T21:21:54

I'm stretching my vim wings lately trying to learn a bit more, and could definitely always use things that make working with Perl easier. If there's any way I could get a 'hey' if you need some help testing, or otherwise twisting and bending these vimish ideas, let me know. Be glad to try and help.

Just don't expect rapid turnarounds, not much of my time is my own in the current present. :)

standard directories

wickline on 2004-12-08T03:53:40

map ,d :!perl -d -Ilib/ %<CR>
Pardon the lengthy introduction, but I hope the context will be of use.... At work, when I start working with a checkout, I do
ww vod_foobarbaz_120987_WORK
The ww means 'work with' (the directory name is subsystem, ticket description, ticket number, and ticket status... so I can spot my trees in QA status easily).

ww is responsible for setting $ENV{CVSWORK} and replacing a few standard symlinks. This lets me refer to sections of the checkout in a standard way regardless of which tree I'm working with or which subsystem (vod, hve, calendar, etc) I'm working with. No matter which tree/subsystem I'm using, the perl lib, web src, scripts, sql defs, and one time scripts are each always at a known static path.

Then, I can use those paths in my .cvswork, my bash functions/aliases and (more significantly for this comment) in my vim mappings. If I do ,g1 I've typed the equivilant of
:n /path/to/current_checkouts/subsystem_specific_perl_lib/
If your checkouts have a consistent structure, then you could have something like ww which you call to start working with a tree. If you have one sort of tree for home and one for work, you could use two flavors of ww or one smart flavor. Then in your vimrc you could have something along the lines of
map ,d :!perl -d -I~/ww/lib/ %<CR>
regardless of where you started vim. Hmmm... Actually, I've got my vim set to consider the directory of the current buffer as its current dir, so no matter where I started vim up, I'd have trouble getting along without ww.

This is also how I can have a bash alias preflight which automatically updates, tests, and spiders the correct subsystem of the current checkout. :)

-matt

Re:standard directories

Ovid on 2004-12-08T16:45:45

These are some interesting thoughts. I particularly like having vim consider the directory of the current buffer as the current dir. This could solve some problems. I'll have to think about how useful the rest would be, though. I think dictating a particular style of work would frustrate people.

Re:standard directories

Aristotle on 2004-12-08T19:34:57

:help autochdir