How do I start, run, and test project-specific modules?
Currently, I'm using module-starter with Module::Starter::PBP to create a set of skeleton files for a new module. If I:
~$ cd ~/job ~/job$ module-starter --module=Foo::Bar
... here's what I get:
~/ job/ Foo-Bar/ lib/ Foo/ Bar.pm t/ 00.load.t perlcritic.t pod.t pod-coverage.t Build.PL Changes ignore.txt Makefile.PL MANIFEST README
I ignore the loose files for now, since I don't see that I need them while developing my project. Getting a module ready for CPAN upload is another task.
There are eight things I think I need to do with the module itself and the files in t/:
These items are only in a rough sort of order; of course there are many cycles of editing and jumping around in that stack. But if my structure fails to let me do any of these eight things, it's a failure.
To use existing CPAN modules on remotehost, I'm required to adjust @INC to include the nonstandard library locations. This cargo cult code amounts to a significant-sized BEGIN block. On both localhost and remotehost, I must include my project-specific modules. (It's a web application so I run under taint mode.) This goes for testing, too, of course.
The naive way to handle this is to ignore testing; to drag the module out of Foo-Bar/ into some lib/ folder included in the project script with use lib qw{ lib/ }. I'm trying to follow my betters and Write Tests First, then write the code.
I've tried several different folder arrangements, with a few different patterns of symlinking and rewriting the .t files. There are complications:
What folder should I cd into? I can open multiple terminals and have each one set to a different folder but that's ugly. It seems to me that whatever is right for running the script is not right for running an individual test; what's right for the individual test is not right for prove -r for Foo::Bar; what's right for the test suite is not right to prove all modules. Ideally, there would be some freedom here; at least to pick a folder and stay there awhile.
In what way do I (should I) compensate for the location of files? The structure seems set up for CPAN upload, not for development with integrated testing. Do I symlink and if so, how?
Should I drag everything out of the Foo-Bar/ folder, develop and test, and copy modules and their tests back later? (Please say no.)
Should I write some sort of Project::Test module that controls the loading and testing of all the rest?
Should I really be patching all the .t files with use lib qw{ lib/ }?
Should I patch prove?
Oh, I get it now. I thought it was "Write tests first; then write code." It's really "Build a test environment first; then write tests; then write code."
So: Fork my current project, throw out all existing code; write three tests, one script, and two modules, none of which do more than 'hello'; then build up a test environment by fiddling with prove and friends. When 'hello' not only works but tests and installs under all regimes, then go back to my project and find out how git merge works.
Thank you moritz and he-who-shall-remain anonymous.
In reply to Module-starter, using modules, and testing by Xiong
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |