I typically edit in a development area. Almost without exception, this is a working copy of the project from CVS.

To answer the second question, I always use h2xs to generate the framework for my modules. So, in the general case, I can put all of my test code in test.pl (or t/whatever.pl, depending on how I'm feeling that day) and running 'make test' takes care of any library path issues for me.

The caveat to this is when the library in question requires the presence of another module in the project currently under development to be tested adequately. In this case, I've been known to take several approaches.

First, I might temporarily adjust the Makefile to have it include the apropriate paths in my library path. I like this solution because it's clean - running 'perl Makefile.PL' undoes whatever damage I did to the Makefile. I dislike this solution for the same reason. I rarely use this method for any project on which I'll be spending more than four hours.

Second, I might set up a better test.pl to convince the module I'm testing that it's got all the bits it needs. chromatic has written an excellent module for this purpose, called Test::MockObject. I like this approach because it feels like the right thing to do - it gives me the satisfaction of a job well done. I dislike this approach because doing the right thing often requires more effort than I really want to expend.

The third method I use for getting around this problem is writing the installation script for the package that I know I'll have to write anyway. Since I only modify the script from project to project, it's no longer as big of a hassle. So, I'll check out the project into another working directory, install it, and run it there for testing. I like this method because all the effort is eventually recycled into making sure my installation procedure is working. On the downside, it requires a lot of extra work - especially for incremental fixes. Checking that your module is at least compilable with perl -c is critical when you use this approach. I almost never use this approach unless I'm fixing a piece of code that's already been released. I never use this approach if I've been good and gone with the second option.

--jwest

-><- -><- -><- -><- -><-
All things are Perfect
    To every last Flaw
    And bound in accord
         With Eris's Law
 - HBT; The Book of Advice, 1:7

In reply to Re: What is your development process for Perl modules and apps? by jwest
in thread What is your development process for Perl modules and apps? by John M. Dlugosz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.