I have been writing a lot of scripts lately---things that I have always wanted to have but never had the time to think about. Now I have lots of time because maintaining my modules while in Iraq has been such a pain (going from a decent development process to this travesty is more than I can bear, and, having only about two months to my return, I have given up for the time being, having made way to many stupid mistakes).
Of course, I have the test bug, and because I know Andy Lester will make fun of me if I do not write tests for my code, I have been writing test suites for my scripts.
This creates a small problem: how do I test only parts of the script, like the subroutines, to make sure they are doing the right thing?
I could put all of the subroutines in a library or separate module, but then it turns into two (or more) files instead of one, and I do not want that for a script.
I could make the entire script a class, and add a run() method to the class, which is sort of the same thing that I see beginning C students do in their main().
int main (
A couple of modules do this. You have probably used one of them:
% perl -MCPAN -e shell
I want to get that same effect with a script, but without as much typing.
I have been musing on some way for the script to figure out how it was called, and if it thinks it was called as a script, automatically invoke its run() method. I have not tried anything, but an END block may be useful since everything else that needs to happen would have already happened. If the script thinks it was loaded through use() or require(), then it acts like a module.
Now, once the script has a class and methods, I should be able to test those individually and independently like any other class. I can even test the whole script by calling it in the right way.
For instance, I have an iPhoto shell that I created in Perl. Everything is a method, and it reads commands then dispatches them. Fine. However, it is also a module, so I can include it inside other scripts and programatically use it. The problem is that I have to know a little bit about what is happening to make it run as a script, and I think that is probably going to be unacceptable to the workaday Perl practitioner. I want it to act like a script when I use it like a script, and act like a module when I use it like a module, and I want to be able to test it both ways.