Objective
-
Tests are able to enable
$modules
, but they are not able to enable$themes
. -
Right now, explicitly enabling themes is not always required, because all themes are loaded at all times.
-
#1067408: Themes do not have an installation status changes that entirely, requiring tests to enable themes in the same way they need to enable modules.
Proposed solution
-
Add
public static $themes = array();
, using the identical logic and behavior as$modules
. -
Adjust
DUTB::installConfig(array $modules)
to accept a first $type parameter.Alternatively, rename it to
installModuleConfig()
and add a newinstallThemeConfig()
.A
$type
parameter would be more in line with the underlyingConfigInstaller
API + extension system though.
Notes
-
$themes
only declares the list of themes to enable. The default theme still has to be configured manually.
Comment | File | Size | Author |
---|---|---|---|
#7 | test.themes.7.patch | 5.44 KB | sun |
#1 | test.themes.1.patch | 5.44 KB | sun |
Comments
Comment #1
sunDepends on code introduced in #1067408: Themes do not have an installation status
Also, we need to adjust
DUTB::installConfig(array $modules)
to either accept a first$type
parameter, or rename it toinstallModuleConfig()
+ add a separateinstallThemeConfig()
. — Adding a$type
parameter would be more in line with the underlyingConfigInstaller
API.Comment #2
sunComment #4
sunComment #5
sunComment #6
sunComment #7
sunComment #9
sunThought about this for some time. I no longer think that a
$themes
facility is a good idea, because it would only encourage bad practices; i.e., testing against a particular theme.The only use-case for enabling a particular theme would be tests of a theme itself. At this point, none of our themes ship with tests, and I'm not sure whether that is a good/sensible idea in the first place. Even if they would, they can use a base class for their tests.
The only aspect that remotely looks useful are the helper methods for DUTB. But even more so for DUTB, tests should not test against a particular theme, but against the default output only.
In short, it is good that this is "hard to do", because you shouldn't be doing it in the first place.
Comment #10
fgmPotential use case : I just had this testing a theme negotiator which ends by asserting that the selected theme is actually enabled. This is a case where the actual theme is not used, but its existence is (via themeHandler->themeExists()).