I wrote https://www.mediawiki.org/wiki/Extension:MediaWikiFarm/Internals#MediaWikiFarm_modes to help reorganizing the tests. See also http://wiki.seb35.fr/MediaWikiFarm_static_analysis (a bit outdated but still useful).

The recent change (-; 6e59c1063fc3 to isolate the configuration in a specific class is one step in this direction (the so-called divide-and-test strategy :-).

Since I redacted this task, I have a less strong opinion about focusing on unit tests. Some thoughts:

• ideally large parts should be splitted in smaller functions, and it will help create unit tests;
• on the other side, integration tests are also interesting ; but they should be labelled as such, perhaps by creating a subdirectory /tests/integration next to /tests/phpunit (both could use PHPUnit, it would reduce the number of dependencies)
• real integration tests could be: 1/ mock some MW parts and check an extension is really activated, or 2/ test scenarios like updating a config file, or 3/ transitionning from no-cache to cache to no-cache. If integration tests are added (and I now think it would be better), a separate task should be created about it.
• I read the Wikipedia article about IEEE 829 - perhaps a bit overkill for such a small software as MediaWikiFarm but I find it interesting, perhaps I will invest the $153 to buy the standard but very unsure for now

In the meantime of all these different orientations, perhaps the current task should focus on small rewritting of the current tests, and split them when possible. Other tasks should be opened (or not) about refactoring the main code into smaller functions, and about create integration tests.

I just fixed a bug where Composer extensions were no more loaded; possibly an integration test could have tested this behaviour and detected the bug.