Test driven development and glue code

Eimi Metamorphoumai has asked for the wisdom of the Perl Monks concerning the following question:

I've recently seen a lot of references to test driven development on the Monastery, and it sounds like a great idea. So I keep wondering whether I can use it. The problem is that as a sysadmin, almost all the code I write is essentially glorfied shell scripts. How can testing be incorporated into code that doesn't really compute values, but instead does something?

For instance, I've got a script that moves users' mailboxes into their home directories (where quota is more strictly monitored) if they get too large. I've got another that kills processes left by users that are no longer logged in (where "logged in" involves checking whether the user has any of various shells still running) and deletes any temporary files they left behind.

The details aren't that important, but what matters is that instead of being a collection of small subroutines that compute values (and can therefore be tested with all sorts of inputs to confirm that they produce the correct output), what I deal with are just big (but usually no more than a screenful or so of text) scripts that interact with the real world. I haven't come up with any automated testing proceedures, but putting one out there untested is very dangerous (when a couple thousand users lose their mail due to a bug, people become unhappy). So I'm doing ad hoc testing by running with the "payload" commented out, and multiple prints all over the place to show what it would be doing, and knowing in my gut that there has to be a better way. So I come seeking wisdom.

What are good approaches you've come up with for this sort of thing? Is there a way to use the Test:: modules with programs like this, or is there another approach that works better?

Back to Seekers of Perl Wisdom