Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/280
As a developer, I shouldn't wait more than a few seconds, so that I can run all the tests
relevant to my changes.
According to Antoine, this is a bad idea, because the point of running the core tests is to check if the extension breaks core.
Thus, if we can't cut the core tests, there isn't much time to gain in the mmv tests.
He also mentioned that soon qunit tests for all extensions will run together on jenkins anyway.
As discussed, the intention is to make manual testing while in the middle of developing a feature faster. The goal would be to allow using something like a Special:JavaScriptTest/qunit/MultimediaViewer URL to limit tests to that extension. (Maybe even more fine-grained tests would make sense, although I am not sure. Even if we call them unit tests, some of our tests are integration tests, and can be broken by changes to seemingly unrelated files.)
https://gerrit.wikimedia.org/r/#/c/151624/
I still have to see if some of the tests can be sped up, don't move this to accepted even if this changeset gets merged/
Either I was blind when I asked for this, or it is a recent development, but there is already a module selector at the top right of the test page, so this is handled already. It is based on the modules defined in the ResourceLoaderTestModules hook, so what we might want to do is break ours up into smaller parts (say, base/ui/models/providers) to make test selection even more granular.
As per meeting discussion, let's redo this in a generic way in core. The idea being that core only would only keep a given subkey of $testModules['qunit'] based on a magic GET parameter.
Btw what the dropdown is based on is the QUnit.module javascript calls (I misread that real bad). But a selector based on the $testModules items would be a nice generic way to handle this, yeah.
The filter parameter pointed out by Timo is certainly enough, it's just not exposed by the UI.