Currently a number of statics such as $conf, and $user and cleared manually by DrupalWebTestCase at convenient times to make the environment cleaner or more in-sync.

As Dries suggested we need a more elegant/scalable solution to this issue, rather than clearing out all the statics manually.

CommentFileSizeAuthor
#11 statics.patch1.56 KBboombatower
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

boombatower’s picture

Title: Provide a scalable way to provide a clean testing environment for SimpleTest » Provide a scalable way to ensure a clean testing environment for SimpleTest
moshe weitzman’s picture

This is probably a dupe of #254491: Standardize static caching which has lost momentum, unfortunately.

Dave Reid’s picture

Something to help me track this issue: I also noticed today that session_id() stays the same outside and inside test cases, which is not the behavior I was expecting.

moshe weitzman’s picture

I was seeing an error in 'Path aliases with translated nodes' which magically disappeared when I cleared a=out and disabled all locale info from my site. So locale is another pace where tainted data is hurting us.
'

boombatower’s picture

Status: Active » Postponed (maintainer needs more info)

Edit: mispost.

boombatower’s picture

Status: Postponed (maintainer needs more info) » Active
hass’s picture

#346844: Clear language statics to remove locale module errors was marked as duplicate of this case from boombatower, but having a mysql dump and repro descriptions. I'm not yet sure if this is a duplicate. Need to read Dries post first. And don't forget to read #334554: SimpleTest: Prevent endless loop and upper timeout during request that have tons of details (http://drupal.org/node/334554#comment-1116879) what's going wrong except of the partly misleading title...

boombatower’s picture

The issue is related to having a module, or any configuration, made in the development environment that SimpleTest is running in that bleeds over to the tests.

Thus your issue fits in that category, and should be used to evaluate any solutions proposed in this issue.

boombatower’s picture

Clearer explanation from, http://drupal.org/node/346844#comment-1258161.

The issue of bleed-over is rather complex and results from the hard-coded statics within Drupal. Many of these statics are reset manually, but there is no clean way to reset them all.

Functions in the following format create this issue.

function get_something($reset = FALSE) {
  static $static;

  if (!isset($static) || $reset) {
    $static = // Do something once.
  }
  return $static;
}

Many of these functions are never directly called by anything other than the system and thus are hard to find and reset in a clean way, other than calling them all with $reset = TRUE.

A revamp of API or some sort of registry with all these functions is needed so they can be cleared cleanly.

boombatower’s picture

Assigned: Unassigned » boombatower
Status: Active » Postponed (maintainer needs more info)

Thought about this for a few days and the only real workable solution I can come up with is to have a static storage facility. Something like the following.

function static_get($name);

function static_set($name, $value);

function static_delete($name);

function static_delete_all();

Either use true statics inside some function and store an array with $name as the key, similar to variables only not stored in db, or just us a global variable like $GLOBALS['STATICS'] for simplicity of API functions (my preference).

A re-write of the function above would like something like the following.

function get_something($reset = FALSE) {
  $static = static_get('static');

  if (!isset($static) || $reset) {
    $static = static_set('static', /* Do something once. */);
  }
  return $static;
}

Might almost make sense to eliminate the $reset parameter on individual functions since it can also be accomplished with static_delete('static'). Which is nice as those parameters are rather useless, seems cleaner.

That way we should be able to reset all statics, core and contrib, by calling static_delete_call()! Which solves the majority, if not all the problems plaguing SimpleTest.

I would be happy to write and implement this in core, just would like opinions/approvals.

boombatower’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
1.56 KB

Initial stab at $GLOBALS implementation.

boombatower’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

boombatower’s picture

Status: Needs work » Postponed
boombatower’s picture

Status: Postponed » Active

The static cache stuff made it in, not sure we should both implementing this as #323477: Increase simpletest speed by running on a simplified profile should alleviate the issue.

boombatower’s picture

Status: Active » Closed (duplicate)
Dave Reid’s picture

I think there are still some issues that can't be solved with the new static API resets. session_id()?

boombatower’s picture

Status: Closed (duplicate) » Active

Actually I believe your right. I will be working on a much better test runner after #449198: SimpleTest: Clean up test loading and related API gets in which should remove some if not all others.

boombatower’s picture

Status: Active » Closed (fixed)

Solved the static issue with drupal_static() although other issues exists they are no where near as important.