Reset module_list() and module_implements() on test setup.

Posted by Darren Oh on April 21, 2009 at 8:12pm

Issue Summary

I don't know if this causes problems in Drupal 7, but with simpletest on Drupal 6, if module_exists() is called during set-up, the result is wrong because the static variable is not refreshed until after the modules are installed.

Attachment	Size	Status	Test result	Operations
drupal_web_test_case.php_.patch	855 bytes	Idle	Failed: Failed to apply patch.	View details \| Re-test

Comments

#1

Posted by Darren Oh on April 21, 2009 at 8:25pm

Patch for Drupal 6 at http://drupal.org/node/440836.

#2

Posted by cburschka on May 20, 2009 at 6:58pm

Title:

Error when installation uses module_exists()

» Reset module_list() and module_implements() on test setup.

Seems to be in order for now, but be aware that module.inc is going to be converted to the static caching API, and these calls may then have to be replaced with drupal_static_reset('module_list') etc. Depending on whether the $reset parameter is removed from these, which is still debated.

The issue to follow is #422370: Revisit and convert mail.inc, module.inc, pager.inc to use static caching API.

#3

Posted by System Message on May 24, 2009 at 11:20pm

Status:

needs review

» needs work

The last submitted patch failed testing.

#4

Posted by Dave Reid on May 25, 2009 at 11:38pm

This patch fixes the errors a lot of us are seeing in D6 and D7 with exceptions with tables not found (cache_update, etc).

#5

Posted by boombatower on May 26, 2009 at 4:48pm

Status:

needs work

» needs review

Re-roll.

Attachment	Size	Status	Test result	Operations
440824-module-reset.patch	908 bytes	Idle	Passed: 11571 passes, 0 fails, 0 exceptions	View details \| Re-test

#6

Posted by boombatower on May 26, 2009 at 10:02pm

Try out: #472684: Install non-default modules one at a time to ensure proper module list is maintained during installation hooks I think it is the parent bug.

#7

Posted by Darren Oh on June 1, 2009 at 2:19pm

The root problem is that the module list from the previous test is being used during the setup the next test. This patch actually fixes the problem, rather than working around it.

P.S. I now see that the other issue fixes the install system rather than the testing system, so it's not a workaround. My main concern was to make the testing system work the same way as enabling modules on the module administration page. That patch would do that.