Background
MediaWiki 1.46 replaced tests/phpunit/phpunit.php with vendor/bin/phpunit. The new runner's bootstrap decides between "unit" and "integration" mode from the test path: a path under /unit is treated as unit-only, and in unit mode MediaWiki does not load its settings or the service container.
Many tests under tests/phpunit/Unit/ are not actually unit tests. They extend plain PHPUnit\Framework\TestCase and construct objects that reach the MediaWiki service container (Message, the service wiring, ParserOutputHelper, the components, ...). Under the old entry point this worked because it always loaded the full environment; under vendor/bin/phpunit they error with Premature access to service container.
As a temporary measure, CI forces the integration-test bootstrap with MEDIAWIKI_HAS_INTEGRATION_TESTS=1 (#97). This issue tracks the proper fix.
Proper fix
Classify the tests according to what they actually need:
- Tests that use MediaWiki services / the database are integration tests: extend
MediaWikiIntegrationTestCase and live outside the /unit path (e.g. under tests/phpunit/Integration/).
- Tests that are genuinely independent of MediaWiki (pure logic, fully mocked) remain unit tests:
MediaWikiUnitTestCase under a /unit path.
Once the service-using tests no longer sit under a /unit path, MediaWiki selects the integration bootstrap on its own and the MEDIAWIKI_HAS_INTEGRATION_TESTS override can be removed from the workflow.
Notes
- The existing
tests/phpunit/Integration/ tests use SemanticMediaWiki test helpers (SMW\Tests\PHPUnitCompat, SMW\Tests\JSONScriptTestCaseRunner), which fatal at PHPUnit collection time when SemanticMediaWiki is not installed. Moving more tests into that suite (or running the whole suite) needs those guarded or SemanticMediaWiki installed.
- The Lua tests (
LuaLibrary*) need Scribunto's 1.46 getEngineName() contract; related but separable.
Done when
- The service-using tests are integration tests (
MediaWikiIntegrationTestCase, off the /unit path) and the genuine unit tests remain unit tests.
- The
1.46/master CI rows run without the MEDIAWIKI_HAS_INTEGRATION_TESTS override, which is removed.
Background
MediaWiki 1.46 replaced
tests/phpunit/phpunit.phpwithvendor/bin/phpunit. The new runner's bootstrap decides between "unit" and "integration" mode from the test path: a path under/unitis treated as unit-only, and in unit mode MediaWiki does not load its settings or the service container.Many tests under
tests/phpunit/Unit/are not actually unit tests. They extend plainPHPUnit\Framework\TestCaseand construct objects that reach the MediaWiki service container (Message, the service wiring,ParserOutputHelper, the components, ...). Under the old entry point this worked because it always loaded the full environment; undervendor/bin/phpunitthey error withPremature access to service container.As a temporary measure, CI forces the integration-test bootstrap with
MEDIAWIKI_HAS_INTEGRATION_TESTS=1(#97). This issue tracks the proper fix.Proper fix
Classify the tests according to what they actually need:
MediaWikiIntegrationTestCaseand live outside the/unitpath (e.g. undertests/phpunit/Integration/).MediaWikiUnitTestCaseunder a/unitpath.Once the service-using tests no longer sit under a
/unitpath, MediaWiki selects the integration bootstrap on its own and theMEDIAWIKI_HAS_INTEGRATION_TESTSoverride can be removed from the workflow.Notes
tests/phpunit/Integration/tests use SemanticMediaWiki test helpers (SMW\Tests\PHPUnitCompat,SMW\Tests\JSONScriptTestCaseRunner), which fatal at PHPUnit collection time when SemanticMediaWiki is not installed. Moving more tests into that suite (or running the whole suite) needs those guarded or SemanticMediaWiki installed.LuaLibrary*) need Scribunto's 1.46getEngineName()contract; related but separable.Done when
MediaWikiIntegrationTestCase, off the/unitpath) and the genuine unit tests remain unit tests.1.46/masterCI rows run without theMEDIAWIKI_HAS_INTEGRATION_TESTSoverride, which is removed.