Hi all,

My simpletest needs to know about the path to a shell command, so I can call:

$command = variable_get('mymodule_shell_command');
if (function_exists('exec')) {
   exec($command);
}

I was under the impression that putting the following in sites/*/settings.php would make my variable available to my simpletest:

$conf['mymodule_shell_command'] = '/path/to/command';

However, in the context of my simpletest, calling variable_get('mymodule_shell_command'); yields null.

The same thing happens if I put a global variable in my settings and try to access it from my simpletest.

I am a bit confused because simpletests have access to at least one variable defined in sites/*/settings.php, the $base_url global.

How would I pass this type of configuration to my simpletest?

Cheers,

Albert.

CommentFileSizeAuthor
#1 drupal-simpletest-settings-conf-2097753-1.patch3.91 KBbrad.bulger
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

brad.bulger’s picture

brad.bulger CreditAttribution: brad.bulger commented
Issue summary: View changes
FileSize
drupal-simpletest-settings-conf-2097753-1.patch3.91 KB

I have a similar but different problem, described in #3204622. I'm working on a local copy of our site, so 'site_name' has one value in the database (copied from the live site) and a different value in my local settings.php file. When the test pages are built, they read the settings.php value. But the test code sees no definition for 'site_name' at all, and expects to find the default value "Drupal" in the test page output. This results in a false test failure.

It was first suggested that this issue had been asked & answered on Stack Exchange - that the original value was available in the setUp() method of the test class before calling its parent's setUp() method. What I found in initial tests, though, was that what was in $GLOBALS['conf'] in the test class setUp() was the value from the database, not the value from my settings.php file.

It turns out that the very first time that the test class setUp() method is called, it does see the value from settings.php. Subsequently, the global variable is erased and rebuilt from the database (or not, apparently, since as mentioned, in the actual test 'site_name' is not set at all).

If you use a static variable in the test class setUp() method and store that first value, and then call variable_set() with it after the parent::setUp() call, you can preserve the original value from settings.php.

I'm attaching some debugging code that demonstrates this. You can recreate the original problem by setting up a generic Drupal 7 site, editing settings.php to add this line, and then running the 'Page cache test' in the Bootstrap test group. BootstrapPageCacheTestCase::testPageCompression() will fail due to a site name mismatch.

$conf['site_name'] = 'My Site';

If you then apply this patch, the test will succeed. It puts out a lot of debug() information about the value (or not) of GLOBALS['conf']['site_name'] as the test progresses.

brad.bulger’s picture

brad.bulger CreditAttribution: brad.bulger commented

I should add, though, that trying this fix with the Token module in my local site, where I first ran into the problem, the test case setUp() methods all only see the value from the database and not the value from settings.php. It works for Token in a generic Drupal installation, so there must be something more going on. So this may or may not work for you.