Debugging your code under SimpleTest when the behavior is different

Question

I'm dealing with a weird problem where a few of my tests are dying from exceptions when run inside of SimpleTest, but I'm unable to reproduce the problem outside of the SimpleTest environment. In particular, it appears that exceptions that I'm catching in my module code get intercepted by SimpleTest before they even leave my try block.

I'm able to debug my test script using xdebug, but for whatever reason, I can't get SimpleTest to pass on the debugger info to my code when it's running under SimpleTest. So when SimpleTest calls $test->run() on one of my tests, the test starts up in its own, SimpleTest-unaware process. And my debugger sits on its hands (they have hands, right?) and runs as if everything is copacetic.

Is there some option in SimpleTest that will allow me to get the XDEBUG_CONFIG environment variable passed on to the subprocesses that SimpleTest spawns?

Answer 1

I have a provisional answer to this, although I'm hoping someone will supply a better one than this one.

First of all, setting XDEBUG_CONFIG as an exported environment variable will let you stop your test script, but not your actual Drupal code. The reason is sort of ugly. SimpleTest interacts with your code using its own mini-browser. So your SimpleTest test runner is as completely isolated from your Drupal application as your browser at home is isolated from the web server you get your page from. There's no connection at all.

So how do we use xdebug via a browser? One way is to set a get parameter, and add the XDEBUG_SESSION_START variable to your URL, like this:

http://my-site-i-want-to-test/node/42?XDEBUG_SESSION_START=my-key

When your test web server sees XDEBUG_SESSION_START, and you have your server set up to connect with your IDE, your server connects up with your IDE, and away you go.

So, here's my not-really-very-good solution to the problem: I get drupalGet and its twins to add XDEBUG_SESSION_START to the string SimpleTest uses to communicate with your server.

SimpleTest is actually using PHP's curl extension to create its mini-browser. If you look at the implementation of drupalGet in WebTestBase.php, you'll see something like this:

  protected function drupalGet($path, array $options = array(), array $headers = array()) {
    // We re-using a CURL connection here. If that connection still has certain
    // options set, it might change the GET into a POST. Make sure we clear out
    // previous options.
    $out = $this->curlExec(array(CURLOPT_HTTPGET => TRUE, CURLOPT_URL => $this->buildUrl($path, $options), CURLOPT_NOBODY => FALSE, CURLOPT_HTTPHEADER => $headers));

    // lots of stuff omitted here...

    return $out;
  }

The $options argument gets passed to $this->buildUrl(), which takes the regular format for URL options. We need to add something to the query string, so we need to pass

$options = [
  'query' => [
    'XDEBUG_SESSION_START' => 'my-key',
  ],
];

This unfortunately requires you to edit your test and pass $options whenever you want to get control of your application via your debugger.

A slightly better solution is to override drupalGet() in your test class, since AFAICT, all the other drupal*() methods ultimately call drupalGet(). In your overrided version, you just append the 'query' info above to the $option array that is passed to it, and then call the original method. You can even watch for a environmental variable in your SimpleTest test script, and only add the 'query' string when you see it.