Change Details

Following up from [https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/](https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/), what are future improvements we can make? Specifically, should removing `tests/phpunit/phpunit.php` and related code be a priority (in favor of the vanilla PHPUnit command `vendor/bin/phpunit`), and if so how do we go about that? Notes: https://etherpad.wikimedia.org/p/WMTC19-T238227

Following up from [https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/](https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/), what are future improvements we can make? Specifically, should removing `tests/phpunit/phpunit.php` and related code be a priority (in favor of the vanilla PHPUnit command `vendor/bin/phpunit`), and if so how do we go about that? Notes: Session: phpunit test runner improvements, removing maintenance class, etc Ticket: https://phabricator.wikimedia.org/T238227 Leads: Kosta Would be nice to… * run the integration tests directly with phpunit, not just the unit tests * move the integration tests into their own directory (core + extensions + skins) * enforce the directory? * get rid of groups / suites? (Which? Both?) ** @group database is a pointless duplication of MediaWikiIntegrationTestCase now. * Get rid of the sub-classes like RLTestCase? ** Maybe move to traits instead of sub-classes? ** Helpful to understand what use cases there are for the different test cases, when who should use which? *** Documentation complexity tied up with this directory ** AGREED: Move RL case into integration directory and rename, etc. * DISCUSSION: Consider moving items to traits? * DISCUSSION: Can we scrap MediaWikiPHPUnitCommand.php and move into phpunit.xml? * Getting rid of some of the old crap may be hard due to use in labyrithine code repos like Wikibase * ACTION: James to add a comment explaining how expectedDeprecated() works. * DISCUSSION: Abort on --use-normal-tables and --reuse-db ? Ask Daniel and Timo? * Could we get rid of MediaWikiUnitTestCase and use PHPUnitTestCase directly with some listeners? ** Hard. But maybe.

Following up from [https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/](https://phabricator.wikimedia.org/phame/post/view/169/changes_and_improvements_to_phpunit_testing_in_mediawiki/), what are future improvements we can make? Specifically, should removing `tests/phpunit/phpunit.php` and related code be a priority (in favor of the vanilla PHPUnit command `vendor/bin/phpunit`), and if so how do we go about that? Notes: Session: phpunit test runner improvements, removing maintenance class, etc Ticket: https://etherpadphabricator.wikimedia.org/p/WMTC19-T238227org/T238227 Leads: Kosta Would be nice to… * run the integration tests directly with phpunit, not just the unit tests * move the integration tests into their own directory (core + extensions + skins) * enforce the directory? * get rid of groups / suites? (Which? Both?) ** @group database is a pointless duplication of MediaWikiIntegrationTestCase now. * Get rid of the sub-classes like RLTestCase? ** Maybe move to traits instead of sub-classes? ** Helpful to understand what use cases there are for the different test cases, when who should use which? *** Documentation complexity tied up with this directory ** AGREED: Move RL case into integration directory and rename, etc. * DISCUSSION: Consider moving items to traits? * DISCUSSION: Can we scrap MediaWikiPHPUnitCommand.php and move into phpunit.xml? * Getting rid of some of the old crap may be hard due to use in labyrithine code repos like Wikibase * ACTION: James to add a comment explaining how expectedDeprecated() works. * DISCUSSION: Abort on --use-normal-tables and --reuse-db ? Ask Daniel and Timo? * Could we get rid of MediaWikiUnitTestCase and use PHPUnitTestCase directly with some listeners? ** Hard. But maybe.