kostajh added a comment.
In T298509#7640564 <https://phabricator.wikimedia.org/T298509#7640564>, @cscott wrote: > In T298509#7633961 <https://phabricator.wikimedia.org/T298509#7633961>, @kostajh wrote: > >> `composer phpunit:unit` will run unit (not integration) tests for core and all skins/extensions, regardless of whether they're enabled, but those tests don't rely on LocalSettings.php so I don't think that's what you're referring to? > > They may not rely on LocalSettings.php but they do depend on `composer update`, references to deprecated methods, etc, so they will certainly fail even if `LocalSettings.php` isn't involved. > > For example, `composer phpunit:unit` at the moment in my tree consisting of only WMF production extensions (but most of them disabled or unconfigured or old checkouts from the last time I had to patch them) fails with 582 errors, ending with: > > 582) Flow\Tests\Data\ManagerGroupTest::testCachePurgeCallsAppropriateManager > Error: Class 'Pimple\Container' not found > > /home/cananian/Projects/Wikimedia/Flow/includes/Container.php:5 > > Yes, in theory I could write a script to `git pull` and `composer update` in each and every checked out extension (282 of them at the moment, and those are just extensions I've personally patched at one point or another), but the point is: phpunit shouldn't be looking at extensions I haven't actually enabled, just because they happen to be present on disk. As an aside, you can use https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin so that you just run `composer update` in the root of the repo, and the merge plugin will handle updates for any extensions/skins. `composer phpunit:unit` by default runs unit tests across core/extensions/skins for convenience, but you could also just run `vendor/bin/phpunit {pathToExtensionTests} {pathToAnotherExtensionTests}` etc, and make an alias or something for convenience. We don't currently have a static listing of enabled extensions/skins, which would be nice IMO, but I don't think it is a good idea to require bootstrapping MediaWiki in order to tell it where tests are. That slows down the overall testing setup and also causes problems for e.g. data providers which don't have any access to the MW anyway in a vanilla PHPUnit setup. In T298509#7640575 <https://phabricator.wikimedia.org/T298509#7640575>, @cscott wrote: > In any case, apart from my general griping, this is the actual issue: > > In T298509#7609799 <https://phabricator.wikimedia.org/T298509#7609799>, @cscott wrote: > >> I don't know how DonationInterface and Wikibase are using this hook, but Parsoid's use is pretty subtle and not obviously easily replaced: Parsoid is *both* a library *and* and extension, and we need to be able to squirrel away Parsoid's "standalone" tests (run by `composer test` without access to a MediaWiki instance) somewhere where core's default auto discovery of tests won't find it -- and similarly, we need to be able to write "extension" tests (which require access to a MediaWiki instance) in a way that the standard `composer test` won't find them. >> >> This is pretty easy to do if extension discovery is done with executable code (or at least a hook to executable code). It seems quite challenging if you're using static `phpunit.xml.dist` files. > > If you allowed extensions to declaratively customize the 'tests/phpunit' subpath, that would probably be sufficient. Parsoid's extension.json could specify that MediaWiki should run the tests in `extension/tests/phpunit` and that MediaWiki should ignore the tests in `tests/phpunit`. Maybe we could implement the workarounds in Quibble, since it sounds like this is a temporary situation for Parsoid anyway? TASK DETAIL https://phabricator.wikimedia.org/T298509 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: kostajh Cc: Krinkle, cscott, kostajh, Jdforrester-WMF, Aklapper, Invadibot, maantietaja, Akuckartz, darthmon_wmde, WDoranWMF, EvanProdromou, DannyS712, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Pchelolo, XenoRyet, Izno, Jrf, Wikidata-bugs, aude, Dinoguy1000, ssastry, Arlolra, Addshore, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
