Fetch PHPUnit dependency through composer #940

merged 3 commits into from Nov 15, 2012


None yet

2 participants

chillu commented Nov 8, 2012

This is an officially supported way of installing PHPUnit 3.7 now.
The more up-to-date devs have been running 3.7 in their own tests for a while, so I don't think there'll be any problems with this version upgrade as such.

One general change necessary was integration of the Composer autoloader in Core.php.
Its only used as a fallback if the SS autoloader doesn't find a class,
so should have minimal performance impact.
@ajshort's work will fix this properly for 3.1 by unifying autoloading into composer (from what I can remember).

I've tried running this in parallel with an older PHPUnit version installed through PEAR (with PEAR being in the standard include_path), and didn't get any problems with redeclared classes etc.

Note: We can't backport this to 2.4, since PHPUnit 3.7 requires PHP 5.3.3+.

As a followup task: Remove the PHPUnit 3.4/3.5 wrappers from framework, and require 3.7. That's probably something for master though. Or can you guys think of any problems this would create? Our build infrastructure has its own managed PHPUnit versions anyway.

sminnee commented Nov 12, 2012

I don't see anything in this that drops the references to the existing PEAR-based PHPUnit installs. Presumably this would be something in PHPUnitWrapper?

Although it would be nice if PEAR were used in situations where composer is missing, I'm not convinced that this pull will actually work in all cases. I would expect the Composer package to be used instead of PEAR if both were installed.

chillu added some commits Nov 8, 2012
@chillu chillu Documenting PHPUnit install through composer 0a580de
@chillu chillu Add Composer autoloader
Mainly to get PHPUnit going as a composer requirement
rather than through PEAR (which is easier to set up).
@chillu chillu Testing docs recommend "phpunit" over "sake"
- Moved some docs around to reflect this change
- Described how to symlink from vendor/bin/phpunit
- Added note about browser-runs not being recommended
- Added more examples on how to run through "sake",
  to complement the existing descriptions for "phpunit"
chillu commented Nov 15, 2012

I've fixed the docs and the @require call. Also added the "phing phpunit" task.
Didn't include composer update --dev in the phing call, as I think that should be left
to the setup process of the project: If the dev decides to use phpunit through composer,
phing will detect its presence. Otherwise it just uses the phpunit binary (most likely installed through PEAR globally).

See silverstripe/silverstripe-installer@04ce08b and silverstripe/silverstripe-installer@e07ae20

Here's some more discussion about using phpunit via composer, just for reference: http://blog.k-fish.de/2012/11/menage-trois-typo3-flow-phpunit-composer.html and composer/composer#1248. BTW, ZF2 uses the same strategy: zendframework/zendframework#2689

@chillu chillu merged commit 8f27e7a into silverstripe:3.0 Nov 15, 2012

1 check passed

default The Travis build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment