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

I'm writing some code that's already over 300 lines long. I'm trying to use TDD and have developed some modules that this code will use. For the modules, the TDD procedure seems obvious to me. has an "evil twin" called module.t and invoking perl module.t from the command prompt runs the tests. But I don't see a way to do this with code that isn't in a module.

The sources I have read indicate that the same technique can be applied. I can see that technique working if the code to be run from the command line is quite short and all that is needed is to test outputs against a relatively small number of inputs. However, I am manipulating Excel. Therefore, the first thing I do is to is to open an instance of Excel. It is not my plan to expose that sub to any external code if I can possibly avoid it, but I do want to write the code using TDD. By the same token, the code should not leave an orphaned instance of Excel open, so the approach of having an external .t file could not test that the finished article even opens Excel, because by the end of the code, the instance would be closed.

The approaches I have considered are:

  • Put (almost) everything in modules. This makes testing easy, but requires more exposure of subs than I want as well as more linkages between modules (and therefore more scope for blunders by me).
  • Accept that some things just can't be tested. But they can, and the tests I have written so far have saved me from storing up lots of problems for myself.
  • 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.

    Can anyone suggest anything better, please?


    John Davies