When a test failed while running on a site with $conf variables in settings.php, I discovered that refreshVariables() loses the $conf variables from settings.php when it resets the $conf array.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | drupal8.test-refreshvariables.14.patch | 2.6 KB | sun |
| #11 | simpletest_refresh_vars-362373-11.patch | 880 bytes | mikeryan |
| #4 | simpletest_refresh_vars_d7.patch | 765 bytes | fago |
| #2 | drupal_web_test_case.php-362373-2.patch | 1017 bytes | darren oh |
| drupal_web_test_case.php_.patch | 820 bytes | darren oh |
Comments
Comment #1
dries commentedMmm. That looks a bit like a hack. At a minimum needs code comments.
Comment #2
darren ohComments included. It's a hack, but rewriting settings.php would be beyond the scope of this issue.
Comment #4
fagoWhat about this approach? (see patch)
I think it's much cleaner and seems to work fine. It fixed the somehow related issue #339210: Support HTTP authentication for me.
Comment #6
fagook, obviously fixing this isn't so simple, but basically this approach should work.
Comment #7
boombatower commentedShould we be detecting $conf settings anyway...since test environment should be separate of host? Or am I missing something.
Comment #8
darren ohThose variables are necessary for accessing the database.
Comment #9
boombatower commentedThis still an issue?
Comment #10
boombatower commentedPlease re-open if still and issue and we have new light on this.
Comment #11
mikeryanI've run into this problem myself - attaching a reroll of Darren Oh's patch (fago's patch does not seem to make $conf variables set in settings.php available to test functions). I haven't done a full test run, but the test that failed on Darren's previous submission passes for me now.
My context is testing an Oracle source driver for the Migrate module. Naturally, the test would need to connect to an Oracle database, and the module looks for connection info in $conf['oracle_db'] (I will have it degrade gracefully to a pass() message describing the configuration requirements if $conf['oracle_db'] is not present).
The patch here only partially fixes my problem - it makes $conf['oracle_db'] available to the test itself, but not to my module's install hook (where the test data is loaded into Oracle). I have a strong suspicion that simply including settings.php somewhere before module_enable() is going to break stuff all over the place, and don't really have to time right now to play any further with this. I can work around it by lazy-loading the source data the first time the migration class using it is constructed, which I had considered doing anyway before implementing it in hook_install().
Comment #12
mikeryanComment #13
sunComment #14
sunAttached patch attempts to add a test (only) for the expected refreshVariables() functionality, which should be committed regardless of the outcome of this issue.
But:
Apparently, setUp() does not include settings.php either.
Comment #17
wodenx commentedThis is definitely still an issue. For me, the problem was running tests on an environment with memcache enabled using different prefixes for different sites. $conf['memcache_key_prefix'], set in settings.php, is lost after the first call to drupalGet(), which resulted in some very difficult to trace cache issues.
Personally, I think Fago's approach is cleaner, and that is what we have adopted (in our own subclass of DrupalWebTestCase).
Comment #18
wodenx commentedIn case anyone else encounters this - here's what we have in our base test class (
class MyBaseTestCase extends DrupalWebTestCase)Comment #19
pieterdcBoombatower, it is still an issue.
Wodenx, that's indeed a workaround but we prefer a fix.
We applied Mikeryan's simpletest_refresh_vars-362373-11.patch to our Drupal 7 distribution.
Sun, thanks for the initial - albeit unfinished - test.
Comment #26
darren ohComment #27
volkswagenchickComment #28
darren ohComment #31
quietone commentedTriaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.
This looks like it a Phpunit issue, changing component.
Comment #32
catchThis is no longer an issue - we don't have the same issue of $conf vs. database variables with the new config/state/settings split, and the $conf global is completely gone.