On Tuesday, February 24, 2004, at 03:53 PM, Martyn Peck wrote:
One of the problems I've run into is that whenever a script uses
Module::Build (using new/resume/current), it always assumes it's in
the package base directory. But when Apache::Test runs the tests, it
changes into the t/ directory. Because of this Module::Build can't
find any of the configuration information. Now I can understand that
when the resume or current method is called, it needs a clue as to
where to look for the configuration directory, but a little educated
guessing wouldn't hurt either. (p.s. I just found out that the next
version of Apache::Test will no longer do this, but it still seems
like something that should be looked at.)
I think in this case educated guessing *will* hurt. Its configuration
information should either be exactly where it expects it to be, or it
should be explicitly told an alternate location. It would be pretty
terrible if it loaded the wrong set of config information and started
using it, you could create a big mess that way.
A closely related and more serious problem I've found is that even
after the resume or current methods are pointed at the configuration
directory, and has $build->{properties}{base_dir} properly set, it
still looks in the current directory for the configuration directory
when trying to load the notes or prereqs file. I've gotten around this
by overriding both the new and current methods, so that
$build->{properties}{config_dir} has an absolute path name, and hope
that nothing tries to use it as a relative path. I've been trying to
put together a patch, but there's allot of code to look through, and I
have too much other work to do, so I won't have one done any time > soon.
I tried to do this myself once, actually. The only reason I didn't
finish was that it was getting awfully messy, but in principle I think
it's a good idea. We could try again.
Another problem I've had is that there's no clean way to separate out
the arguments specifically needed by Apache::Test in other scripts. I
don't want to have to parse $build->{args} in every single test file,
but I don't see any place where I can easily do this in one pass. I
ended up rewriting the merge_args method to separate out the
Apache::Test args and put them in a notes tag. And that won't work
anymore when I also start using DBIx::Test.
I'm not sure I understand this point very well, could you give me a
concrete example?
Speaking about DBIx::Test, I'm having trouble figuring out how I would
use it along with Apache::TestMB. The module itself is straight
forward. It just need to get some config arguments from the command
line, setup a temp database use those configs before tests are run,
and to clean up the temp database after the tests are finished. But I
can't figure out any way to use it with Apache::TestMB in any way. I
can't do any kind of inheritance, since any action they both have
(like a pre-test setup) will only get run for one of them. I could
make a third module that calls each method explicitly from the other
modules, but that's apt to break very easily. So far, I've been
writing it as a sub-class of Apache::TestMB, but this is obviously
only a temporary solution, and not good for any production code. Any
ideas?
I'd recommend that in your M::B subclass you get configuration
information, store it in notes(), then do your setup/teardown in an
overridden ACTION_test() method. If the regression test scripts
themselves need to get at configuration information, they can use
current()->notes() to get it. Does this sound workable?
I've included two small patches for bugs I've found. The first patch
is for the Base.pm file. I found that if the recursive_test_files
option is given it will find the test files, but not sort them, as I
need for my tests. I've been getting around this by listing the test
files explicitly, but slowly getting annoying as the number of tests
keep growing. The second patch is for the Compat.pm file. When I was
writting Apache::TestMB I wanted to make sure it was completely
reverse compatible with Module::Build, so I just took all the existing
tests and changed the names form Module::Build to Apache::TestMB, and
then found out the generated Makefiles failed, because they never used
Apache::TestMB.
Thanks, I'll take a look.
-Ken
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
|
