Add support for xdebug in WebTestBase

There's definitely a need to be able to step into / break inside drupalGet()/drupalPost().

I don't have a good grasp of the variety of debugging solutions, but isn't proposal a) a sort of a mandatory solution, which would always slow down your test runs, even when you only want to debug the test, without any need for stepping into drupalGet()/drupalPost()?

Thank you. I haven't been desperate enough yet, but I'll try it when I need to.

Reopening.

Having to set up a separate Apache virtual server, or patching WebTestBase on and off again and again is a pain.
Could be as simple as WebTestBase::curlExec() forwarding XDEBUG_SESSION_START if it finds it in the cookie ?

Retitling.

Patch.

Yeah, that's exactly what I need too!
I was using something like this so far in WebTestBase::curlExec():

    // Forward xdebug session.
    if (isset($_COOKIE['XDEBUG_SESSION'])) {
      if (!isset($curl_options[CURLOPT_COOKIE])) {
        $curl_options[CURLOPT_COOKIE] = '';
      }
      if (!empty($curl_options[CURLOPT_COOKIE]) && substr(trim($curl_options[CURLOPT_COOKIE]), -1, 1) != ';') {
        $curl_options[CURLOPT_COOKIE] .= '; ';
      }
      $curl_options[CURLOPT_COOKIE] .= 'XDEBUG_SESSION=' . $_COOKIE['XDEBUG_SESSION'] . '; ';
    }

    curl_setopt_array($this->curlHandle, $this->additionalCurlOptions + $curl_options);

But I can't say if there's a difference between passing the xdebug session as url parameter or as cookie.

I tried out the patch but it didn't worked for me. Maybe that's just my setup of xdebug.

Yched helped me out: For some odd reasons PHPStorm had setup a max. amount of connection to 1, so the subconnection didn't got picked up.

+        $options = drupal_parse_url($curl_options[CURLOPT_URL]);
+        $options += array('query' => array());
+        $options['query'] += array('XDEBUG_SESSION_START' => $_COOKIE['XDEBUG_SESSION']);
+        $curl_options[CURLOPT_URL] = url($options['path'], $options);

url() is really not meant for that. If you really want to do URL parsing this late in the process, use lower-level functions.

Well then, here's my approach as a patch.
Only thing I'm still not sure about is whether there's a difference between using cookies or an url parameter (I don't think so) and if setting CURLOPT_COOKIE could interfere with the cookie handling in the tests (I actually had never a problem with that).
Let's see what the testbot says.

#13 works for me too.

I'd suggest this slightly simpler shape for the code though :

      $curl_options += array(
        CURLOPT_COOKIE => '',
      );
      // Ensure any existing cookie data string ends with the correct separator.
      if (!empty($curl_options[CURLOPT_COOKIE])) {
        $curl_options[CURLOPT_COOKIE] = rtrim($curl_options[CURLOPT_COOKIE], '; ') . '; ';
      }
      $curl_options[CURLOPT_COOKIE] .= 'XDEBUG_SESSION=' . $_COOKIE['XDEBUG_SESSION'] . '; ';

Good idea, and here we go.

It works really great if you have allow three external connections in your debugger. Here is some more explanation and documentation.

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -1044,6 +1044,24 @@ protected function curlExec($curl_options, $redirect = FALSE) {
+    // so you can't debug actual running code. In order to make debuggers this

Make debuggers work?

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -1044,6 +1044,24 @@ protected function curlExec($curl_options, $redirect = FALSE) {
+    // at least 3 external connections.

Not sure if this should be 'three' - maybe xjm is a good person to ask. I will make the wrong decision here :)

Just corrected both.

This looks good to me - and I'd like to set it to RTBC.
However it would be great if we had something like http://drupal.org/debugging or http://drupal.org/xdebug to document how to use debuggers / set up IDE's and add the link to the doc-block.
I hope we'll create such a page today at the DrupalCon Portland sprint.

Bump - this has been a total life saver for the past month :-)

Let's do this!

I didn't manage to create the document page as I hoped :| And there was a discussion about supporting cli (no cookies) and zend debugger.
However, there's nothing wrong with the current implementation and it's really handy.
Thus +1 for getting this in asap.

Committed f63db4c and pushed to 8.x. Thanks!

Follow-up (sort of): #2134259: Make the Simpletest XDebug integration work for CLI requests

Am I the only one for which this doesn't anymore ?
When running a WebTest, setting a breakpoint in the "tested" side just seems to make the curl_exec() call in WebTestBase::curlExec() just die.

(note: I started seeing this a couple weeks ago, well before #2134259: Make the Simpletest XDebug integration work for CLI requests was added)

Probably not important here - but in my case, curl_exec() just hung indefinitely (not crashed).

After a day of tracing the problem I found out I am apparently starting PHPStorm debug sessions 'the wrong way'. Updated docs.

Let's see if we can get this backported.

And here goes a patch.

This worked for me and I'm using codebug http://codebugapp.com/ which isn't integrated with an IDE, so it took a couple extra things..

1) This REQUIRES setting a cookie during your request when viewing the tests page. To do that outside an IDE, I just used the chrome plugin. https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjb... It looks like using this url will set the cookie as well: admin/config/development/testing?XDEBUG_SESSION_START=XDEBUG_ECLIPSE

2) using xdebug_break(); for initial breakpoints worked since it's more tricky to set breakpoints with my setup, but once that fires, I can add additional breakpoints.

=== UPDATE ====

Correction, this doesn't seem to work on subsequent requests. I see calls that look correct to say the contact form when running the contact tests ( http://d7dev.local/contact?XDEBUG_SESSION_START=XDEBUG_ECLIPSE) but my xdebug_break(); calls in contact.pages.inc seem to be unheeded.

This was the code i used for the contact module..

function contact_site_form($form, &$form_state) {
  global $user;
  xdebug_break();
 // Check if flood control has been activated for sending e-mails.
 //...

Some other notes: I'm using php 5.4.36 in this environment and many tests are failing

OK, so I finally got this to work. Some other details of my environment is that I'm working on a vagrant VM so that adds some wrinkles too..

1) If you are running tests via simpletest module on a VM, you need to make sure that xdebug.remote_connect_back is disabled, and you use the xdebug.remote_host setting instead (with the IP address of the xdebug client from within the VM.. like xdebug.remote_host = 33.33.33.1 for my machine. xdebug.remote_connect_back will clobber remote host, and since the requests are basically coming from localhost when drupal sends them, it will be looking for an xdebug client at 127.0.0.1:9000 instead of your actual machine.

2) At least for my debugger, it seems to get somewhat messed up with multiple sessions. What I had to do to get it working finally was to only enable the debugger AFTER I started the tests running. Then each separate request is handled by the debugger, including xdebug_break() breakpoints. I'm guessing that once the session starts for the test-runner itself, the debugger doesn't pick up on the new sessions and just ignores them.

3) Don't forget to set your local /etc/hosts file so that your development url continues to work when requested locally. For me it's d7dev.local, so I had to add that to the VM's /etc/hosts file as well. All the errors I was getting was because it was making requests and getting the default apache response :/ That also means that my custom breakpoints never had a change to run, because the right code wasn't being called by the drupal tests.

4) A simple way to test things are working before even testing this patch is to use curl from the command line like so : curl http://mysite.local?XDEBUG_SESSION_START=XDEBUG_ECLIPSE .. replace XDEBUG_ECLIPSE with whatever string you have configured with your IDE. If you are working with a local VM, then make sure to run the curl command within the VM (ssh in and run it).

Testbot fluke.

Looks like this should help some people, and be harmless for everyone else :)

Committed to 7.x - thanks!