Page MenuHomePhabricator

Migrate parser tests to new phpunit:config mechanism
Closed, ResolvedPublic

Description

Instead of using the dynamic suite mechanism, parser tests should be modernized to use the new phpunit:config mechanism to generate a static list of all parser tests.

Event Timeline

Change #1281759 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/services/parsoid@master] WIP: Generated phpunit tests for parser tests

https://gerrit.wikimedia.org/r/1281759

Change #1287963 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] PHPUnit 10 compatibility for parser tests via non-suite runner

https://gerrit.wikimedia.org/r/1287963

Change #1287963 merged by jenkins-bot:

[mediawiki/core@master] PHPUnit 10 compatibility for parser tests via non-suite runner

https://gerrit.wikimedia.org/r/1287963

Thanks for doing this :) Can this task be considered done now, and the parsoid part be filed as a separate task? (So that we can formally unblock the parent task)

FWIW, given Parsoid will soon be used pretty much everywhere, we'll need Parsoid parser test runs to be included as part of the coverage since core parser tests will be disabled.

It seems composer phpunit:config adds new files but does not remove old files that would no longer know to ensure/create. Is there something preventing these from being run (i.e. are they left behind but otherwise de-referenced) or would also be discovered and run by PHPUnit?

It seems composer phpunit:config adds new files but does not remove old files that would no longer know to ensure/create. Is there something preventing these from being run (i.e. are they left behind but otherwise de-referenced) or would also be discovered and run by PHPUnit?

Discussed during review at:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1287963/6..9/tests/phpunit/generatePHPUnitConfig.php#b155

These tests are added as files to the suite. Instead we could add the entire tests/phpunit/gen directory at once, but that would require garbage-collecting the directory contents to remove old tests if the set of extensions or the set of parser tests changes. I'd rather not have composer deleting stuff in the course of running tests, so I'm explicitly enumerating files instead. You can always blow away your entire tests/php/gen directory if you want to clean house and it will be rewritten, but I haven't added an explicit "clean" operation.

tl;dr we don't auto-discover tests in the gen/ directory so extra files are harmless. The set of parser test files changes extremely infrequently -- and almost always it is new files that are added, not existing files removed -- so it's not expected to generate much garbage.