• Put the tests in the code to be executed from the command line. This is the approach I am currently using, but I see a problem ahead. When the development is finished, I don't want the tests to run every time. I imagine that this will mean that I will have to put in code to handle options so that code -t will run tests while code filename will do the real work of processing a file.

That sounds like a sensible idea. You could add a --self-test command line switch, and have it on by default during development, and off when the code is complete. You could even put the test code into a separate .pm file (in the same package) so that you don't have to ship the test code in your deliverable.

An alternative approach would be to create a .t test script that loads and executes your main program, either using system() with a test command line, and then examines the output, or by loading the whole script into a scalar string, and using eval()

Overall though I think it is wiser in the long term to take moritz's advice and make your script act as both standalone and as a module with doit(@ARGV) unless caller; at the end of all your subroutine definitions