Page MenuHomePhabricator

Run test suites for all captcha types in ConfirmEdit
Open, LowPublic

Description

Aren't there structure tests in mediawiki-core which should be run on all extensions and checking the autoload to avoid failure like T100775?

Why for this (and may other extensions) the mwext-testextension-zend is not running (instead mediawiki-extensions-zend is running).


Test suites just testing the "main" extension, not any of the captcha types which can be activated by config.

Event Timeline

Umherirrender raised the priority of this task from to Low.
Umherirrender updated the task description. (Show Details)
Umherirrender added a subscriber: Umherirrender.

mediawiki-extensions-zend is a Jenkins job that clones several extension together and then runs phpunit --testsuite extensions. On those extensions, the mwext-testextension-zend is no more run.

I looked a the test results of patch proposed to master/REL1_25 and they have the structure tests being run. Whatever caused T100775 does not seem to be covered by any test :-/

ConfirmEdit is messed up because we test the "main" exception, but none of the sub extensions contained in it. We really need to split it into multiple extension repositories.

Umherirrender renamed this task from Run structure tests on extensions/ConfirmEdit to Run test suites for all captcha types in ConfirmEdit.May 29 2015, 9:02 PM
Umherirrender updated the task description. (Show Details)
Umherirrender set Security to None.

ConfirmEdit is messed up because we test the "main" exception, but none of the sub extensions contained in it. We really need to split it into multiple extension repositories.

Thanks for the hint. I have change the description.

The extensions sub classes have been split to enable extension registration T88047 . I am not sure why they had to be split to different sub extensions though :/

ConfirmEdit is messed up because we test the "main" exception, but none of the sub extensions contained in it. We really need to split it into multiple extension repositories.

s/exception/extension/ ?

Is this a once-off problem, or are there other extensions which are similarly messed up?
Does there need to be a process to prevent these messed up extensions being deployed to Wikimedia production without sub-extensions being tested?

Dropping CI config, that should be done in the extension test suite if there is still any interest in this.

I am not sure why they had to be split to different sub extensions though :/

The problem is, that the extensions are loaded by one of two ways:

  • The repository name, if the repository is/was a dependency for the current build (it's either the repo name (mediawiki/extensions/ConfirmEdit) or the extension name (ConfirmEdit))
  • There's a directory under extensions, which has an extension.json or an php entry point

For both ways, the "sub-extensions" of ConfirmEdit are not recognized, as they're in subdirectories. So we could either change the extension loading process to take all extension.json files of a whole extension into account (even if there're more than one extensions) or split up the ConfirmEdit extension into multiple extensions. I'm not sure, what the better idea would be. However, I remember, that @brion had something "against" splitting the extension up, irrc :/