Page MenuHomePhabricator

wfWikiID() returns different values from test and data provider
Closed, DeclinedPublic


This fails when running a test that extends CentralAuthTestCaseUsingDatabase:

 * @dataProvider provideWfWikiID
public function testWfWikiID($expect) {
    $this->assertSame( $expect, wfWikiID() );

public function provideWfWikiID() {
    return array(
        array( wfWikiID() ),

CentralAuthPluginUsingDatabaseTest::testWfWikiID with data set #0 ('wiki')
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@

I tried to use $this->dbPrefix() inside the provider to kludge the right value and got a failure with this stacktrace which might help figure out where we could initialize $wgDBprefix to get consistent behavior:

Fatal error: Call to a member function getType() on a non-object in /vagrant/mediawiki/tests/phpunit/MediaWikiTestCase.php on line 400

Call Stack:

0.0008     253704   1. {main}() /vagrant/mediawiki/tests/phpunit/phpunit.php:0
0.2053    8666952   2. MediaWikiPHPUnitCommand::main() /vagrant/mediawiki/tests/phpunit/phpunit.php:160
0.2053    8680808   3. PHPUnit_TextUI_Command->run() /vagrant/mediawiki/tests/phpunit/MediaWikiPHPUnitCommand.php:42
0.2263    9419016   4. PHPUnit_Runner_BaseTestRunner->getTest() /vagrant/mediawiki/vendor/phpunit/phpunit/src/TextUI/Command.php:153
0.2502   11030928   5. PHPUnit_Framework_TestSuite->__construct() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Runner/BaseTestRunner.php:138
0.2587   11389784   6. PHPUnit_Framework_TestSuite->addTestMethod() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Framework/TestSuite.php:219
0.2588   11390232   7. PHPUnit_Framework_TestSuite::createTest() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Framework/TestSuite.php:800
0.2590   11394056   8. PHPUnit_Util_Test::getProvidedData() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Framework/TestSuite.php:472
0.2591   11398136   9. ReflectionMethod->invoke() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Util/Test.php:377
0.2591   11398208  10. CentralAuthPluginUsingDatabaseTest->provideAuthenticateWithPreRenameUsername() /vagrant/mediawiki/vendor/phpunit/phpunit/src/Util/Test.php:377
0.2592   11398320  11. MediaWikiTestCase->dbPrefix() /vagrant/mediawiki/extensions/CentralAuth/tests/CentralAuthPluginUsingDatabaseTest.php:205

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz68231.
bzimport added a subscriber: Unknown Object (MLST).
bd808 created this task.Jul 18 2014, 7:25 PM
  • Bug 68650 has been marked as a duplicate of this bug. ***

bug 68650 logged the same issue with ProofreadPage\FileProviderTest::testGetForIndexPage and ProofreadPage\FileProviderTest::testGetForPagePage

Thanks for filling this bug. I have noticed that when running the PHPUnit test suite with the wmf deployed extensions (bug 67216).

An example run is:

CentralAuth is not used in that job because of an unrelated issue (it has a central database). But ProofreadPage (was bug 68650) definitely does.

Change 150169 had a related patch set uploaded by Hashar:
test: coverage for wfWikiID()

About the stacktrace: PHPUnit providers are static functions which are evaluated before the test run. So you can not rely on the object state (i.e. $this->dbprefix does not exist).

Change 150169 merged by jenkins-bot:
test: coverage for wfWikiID()

bd808 added a comment.Jul 29 2014, 3:44 PM

I have a work around for the particular test where I encountered this problem originally:,unified

Krinkle closed this task as Declined.Jan 13 2017, 2:14 AM

Similar to T136348. Avoid calling external code from data providers. Virtually all code should run inside the test. The providers should just be static/declarative data to inform what to do inside the test.

It'd be better to call wfWikiID() as first line in the test function instead of from the data provider. Especially because it's by design that it may vary from one test to another (in parallel test execution, one could be two different temporary-table copies of the database, at which point the static data provider called ahead of time would have the wrong information)