kentcowgill.org/blog

&qidYou may have guessed by now, but I've taken up a particularly onerous gauntlet at my job. I'm afraid to touch any modules. But holy cow, do they need touching.

What do we learn from Refactoring: Improving the Design of Existing Code ? Well, we learn that without tests, you can't refactor. Well, you can - it's really not wise to do so, however. It will be difficult to know if you've broken something or slightly altered a particular functionality.

Of course, tests also help you prove what you've got is a set of modules that performs to their specifications - or in the absense of a specification - proving that the code does what it looks like it's supposed to do based on certain circumstance.

Given that our codebase is huge, undocumented, and more important untested, I've come up with a few snippets of shell code to really move me pretty far forward with my task.

First, to create a directory hierarchy to house all my new tests:

for i in $(find . -name "*.pm")
  do touch $(echo $i | \
           sed -e 's/\./\/path\/to\/dir/' | \
           sed -e 's/\.pm$/.t/')
done

And to give the files some default content (it's ugly but it sorta works, YMMV):

for i in $(find . -size 0)
  do echo '#!/usr/bin/perl' >> $i
    echo "" >> $i
    echo "use strict;" >> $i
    echo "use warnings;" >> $i
    echo "" >> $i
    echo "Test::More 'no_plan';" >> $i
    echo "" >> $i
    echo "use_ok( '`sed -e 's/\//::/' | \
      sed -e 's/\.t//'`' );" >> $i
  done

These snippets, plus my previously mentioned vim tip are really getting me pretty fair along in creating a comprehensive test suite and a good set of documentation for all of our legacy code.

Oh, and as a side benefit, I'm getting to know the modules pretty well while I'm at it :)