How'd you do that?

• I develop my modules located within the site/lib structure.
• I embed the tests within the module after

  return if caller;
  package main;
  
  # tests here
  [download]

  Thus, when run as a script: perl \perl\site\lib\my\module.pm, the tests are run.

  My editor has the facility to run the current file supplying the full pathname. The results are logged directly into another editor pane.

  Clicking an error message that contains a line number switches me to that pane/line number (loading the file first if it isn't already loaded).

• I don't use perl Test::* packages or prove etc, because they:
  1. Steal my stdout/stderr output;
  2. and/or futz with it in ways that prevent me from seeing it in real time;

     For example, prevent me from using ^S to pause the program run whilst I check things: Memory usage, open file and other OS handles; file output; etc.

  3. Require me to force fit all my tests in dumb boolean ok/nok outcomes.
  4. Seem mostly concerned with producing a bunch of meaningless statistics I have no use whatsoever for.
  5. Generally interpose themselves between me and my code, forcing me into a most unnatural, clumsy and laborious way of working for the sake of a set of 'benefits' that I do not see the value of.

• Finally, if and when I get a module to the state where I think it might be useful to others, then I will consider 'packaging' it.

  At which point I will do the absolute minimum required to allow it to be uploaded to CPAN and installed via that mechanism.

  Prior to that point, the whole archaic, ill-fitting blib structure, and make/test/install working practice is nothing more than a drag on my time. A pain to set up; a chore to maintain; and little more than make-work to operate.

• I do not currently use source control software.

  I have set up several different flavours of it here over the past few years -- svn; mecurial; darcs -- but as I tend to prefer not to collaborate with others, I find their benefits minimal and far outweighed by the affect they have upon my working practices and productivity.

  One day someone will write the perfect source control package and I will use it. Instead of forcing me to work to its agenda, path structures etc. it will fit to mine. It will run on startup and sit in the background with an icon in the task area.

  When I want to have it control something, I will pop up an explorer dialog and click on one or more paths in my file system. And then I am done. From that point on, it will monitor all those directories and when a new file (or directory) appears or a file within them changes, it will do its thing. And each time they change, it will do its thing.

  No further action required from me. Until I want to revert a file, at which time I'll click the icon, locate the file or directory I wish to revert and then it will allow me to click back through the changes made until I reach the point I wish to revert to. Click doit, and it will be done.

  Maybe I'll write it one day :) (And pigs might fly, world hunger will end and all will be right with the world :)