Let SimpleTest test the theme system

This was discussed about a year ago (never officially) and kinda fell by the wayside.

I think the best way to test the theme layer is to create a "SimpleTest Theme" which seems like the track you're on with hidden = TRUE. Then implementing all possible override combinations and such and testing them by viewing the appropriate pages.

It would be nice to have a $this->setTheme(); method so the setUp() for a theme test could look like

function setUp() {
  parent::setupUp();
  $this->setTheme('SimpleTest');
}

The SimpleTest theme should be very "computer friendly". Each template can simply place a wrapper div around content with an id value representing the template. Or if we don't care about HTML we can go XML route and just make the tag the template id.

So what do we need? The tests can goto the theme page and change the active theme.

Please provide more details. The issue linked to has all passing tests?

I am for supporting hidden = TRUE in themes. I'll work on a patch shortyl.

Here's the patch. :-)

I was surprised how easy this was to implement, but it was super easy to copy the necessary code from system_modules().

I think themes/tests/THEMENAME works. And we can't have just one simpletest theme because we need to test inheritance of base/sub themes.

Rerolled to fix a few code comments up Update status now that themes can be hidden, too (_update_process_info_list() is already ignoring them, but the comments assumed those where for hidden modules). I'm going to try writing a test for #456088: Sub-themes not notified of security updates for base themes that depends on this patch, and if that all works nicely, I'll mark this RTBC.

New patch that also adds a themes/tests/README.txt file. If you use this, you'll need:

cvs add themes/tests
cvs add themes/tests/README.txt

It'd still be nice to have an easy way to enable these themes via test cases. For now, I'm just doing the following, which isn't ideal:

  db_update('system')
    ->fields(array('status' => 1))
    ->condition('type', 'theme')
    ->condition('name', 'update_test_subtheme')
    ->execute();

Otherwise, this is definitely working. I can add test themes under themes/tests/*, they don't show up at the "Appearance" page, but when I alter the .info files inside update status tests, it all works as expected. I'm tempted to mark this RTBC at this point, since we can always add the $this->setTheme('theme_name') function later, or other support mechanisms to make this easier. But, without the basic plumbing of hidden themes and a themes/tests directory in core, we simply cannot write tests that involve themes...

Looks like a good start. I say we followup here or in separate issues for DWTC->setTheme() and maybe a function that can be re-used by both module and theme listings to 'hide' required or testing projects.

function theme_dww_and_johnalbin() {
  return 'Awesome'; // Untranslatable, because they are too awesome.
}

Very minor text formatting change in themes/tests/README.txt to make it match the format of other README files in sites/all/. Otherwise identical, so still RTBC.

Sweet, thanks webchick!

First follow-up: #456088-30: Sub-themes not notified of security updates for base themes. Should be RTBC, although it's my patch so I didn't say so. ;)

BTW, once #456088 lands (or any patch that adds some hidden test themes like this), we could add a test in theme.test to ensure that the hidden themes aren't showing up on the Appearance page. ;)

Marking for backport to D6. This is important stuff!

The following code allow to set a new theme in simpletest D6 testcases:

  protected function setTheme($new_theme) {
    $this->assertTrue(db_query("update {system} set status=1 where type = 'theme' and name = '%s'", $new_theme), "Theme: $new_theme set as default");
    variable_set('theme_default', $new_theme);
    unset($GLOBALS['theme']);
    init_theme();
  }

Seems like this is long since dead.