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
| [reply] |
I don't recall if/where we discussed this earlier, but I remember talking about it (if there is such a discussion, finding it ought to give you extra insight), but anyway, what I do is described somewhat at
http://crazyinsomniac.perlmonk.org/perl/bmm/.
When testing stuff, I write unit tests, which I run from the commandline.
Also, I have a virtualhost dev.localhost, whose
root is my dev directory (cvs checkout area), that way
I don't install any module I'm developing until it's tarred'n'gzipped (and maybe up on CPAN or someplace ;).
Also, I generally don't install modules I'm developing on my test machine, cause I use this setup.
In case you can't reach my website, here's what one of my typical dev directories looks like
E:\DEV\BMM
| bmm.cgi
| bmm.cgi.err.log
| bmm.cgi.err.log~
| bmm.cgi~
| BMM.pm
| BMM.pm~
| bmm.sql
| HeadQUE.pl
|
+---BMM
| | DBI.pm
| | DBI.pm~
| |
| \---CVS
| Entries
| Repository
| Root
|
+---CVS
| Entries
| Repository
| Root
|
+---t
| | dbi.t
| | dbierr.t
| | url.t
| |
| +---CVS
| | Entries
| | Repository
| | Root
| |
| \---op
| | add.html
| | add.t
| | add.t~
| | edit.html
| | edit.t
| | edit.t~
| | newuser.html
| | newuser.t
| | newuser.t~
| | pod2htmd.x~~
| | pod2htmi.x~~
| | statuscheck.t
| | view.html
| | view.t
| | view.t~
| | xml.t
| | xml.xml
| |
| \---CVS
| Entries
| Repository
| Root
|
\---tmpl
| bmm.about.html
| bmm.about.html~
| bmm.add.html
| bmm.add.html~
| bmm.edit.html
| bmm.edit.html~
| bmm.html
| bmm.html~
| bmm.index.html
| bmm.index.html~
| bmm.newuser.html
| bmm.newuser.html~
| bmm.statuscheck.html
| bmm.view.html
| bmm.view.html~
|
\---CVS
Entries
Repository
Root
This works pretty well for me, and I suspect would for others too, but YMMV.
____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy. | [reply] |
On my home boxen, I keep ~/devel/bin and
~/devel/lib directories (and
~/devel/include for C stuff) for software I'm
writing. (The source usually goes in an appropriate
directory somewhere in ~, although if the s/w's
just one file I'll edit it directly in
~/devel/foo.) All CVSed, of course.
At work, everything lives in a develop directory (oh,
sorry, folder) until I'm comfortable deploying it.
--
|
F
o
x
t
r
o
t
U
n
i
f
o
r
m
|
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!
|
| [reply] |