Re: Please contact package maintainer before to do something
[email protected] (Daniel Convissor) Tue, 3 Jan 2012 13:49:20 -0500
| Newsgroups | php.pear.qa |
|---|---|
| Message-ID | <[email protected]> |
Hi Laurent:
Please accept my apologies for stepping on your toes. You're right, I
should have contacted you.
> And I'm not sure this is the right solution applied here.
> First : You missed a file
> pear/packages/Net_Growl/trunk/tests/AllTests.php , that didn't use
> the new dir structure
That file picks up the autoload file from the included test files.
> With path like 'Net/Growl/Autoload.php' you will use the installed
> version in system of Net_Growl and not the SVN working copy
PEAR's tests should be configured to (at least) run properly from the
base directory of the package's checkout, so in a structure like this:
Net_Growl
Net_Growl/Net
Net_Growl/Net/Growl
Net_Growl/tests
One cd's into Net_Growl and calls the tests via one of the following
ways, for example, depending on the way tests are set up:
phpunit tests
phpunit tests/AllTests.php
pear run-tests -r tests
This way the "." in the include path pick up the "Net" and "Net/Growl"
directories so local files are found, as desired.
In some test suites, such as pear-core, I hard code the include path based on
whether one is in a checkout or an installation. This permits one to
run the tests from any location, which can be helpful if there are lots
of tests and/or test sub-directories.
> I prefer to use a solution like the XML phpunit configuration file
> <phpunit bootstrap="../Net/Growl/Autoload.php">
This approach has problems. If you put the file inside the tests dir,
it does not get picked up when running "phpunit tests" from the
Net_Growl directory, as is the normal practice. If you put the
phpunit.xml in the Net_Growl directory, where will that end up when
installed and what will happen when running "pear run-tests" for the
installed package?
> C:\home\pear\Net_Growl\trunk>phpunit -c tests/phpunit.xml tests/
While the package's particular Jenkins build commands can be set up to
run the tests like that, that doesn't solve the problem for random
developers who are just trying to run the tests on an ad hoc basis in
their personal checkouts. Plus it's a custom configuration for Jenkins,
so the more packages that do that, the more complex things get to
manage.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409