Since simpletest is meant for testing/development, it would be helpful if it fully supported debugging.
As things are now, if you want to debug what happens inside the drupalPost/drupalGet requests in Simpletest [debug in the sense of "step through the code in a debugger", such as xdebug or Zend], you have to do something like what is described on the bottom of this page:
http://drupal.org/node/30011
Namely, you either need to set up a separate Apache virtual server and use that, or you need to hack drupalPost/drupalGet to add something like this near the top to add the debugging session information to the URL before it is passed through curl:
if (!isset($options['query'])) {
$options['query'] = array();
}
$options['query'] += array('XDEBUG_SESSION_START' => 'ECLIPSE_DPGP');
It would be nice if SimpleTest could do this automatically. Two methods I thought of:
a) Detect an XDEBUG_SESSION_START cookie in the environment when the test is launched, and do the above if it's there. This could be problematic, because you may not be able to anticipate exactly what environment variable you're looking for, depending on how people debug (e.g. xdebug vs. zend - I have no idea what the env variable is for zend, and are there other debuggers?). So that's probably not the best idea.
b) Have a config option to add query variable(s) to all URL requests. It could be set up so that on a config screen, you would enter "XDEBUG_SESSION_START" in one box, and "ECLIPSE_DPGP" in another (or whatever the equivalents are for your particular debugging setup), to define your debug environment variable needs, and then have a "debug these tests" checkbox on the "Run Tests" screen. If the box was checked and the options were set, the code above would be added to drupalGet/drupalPost before the cURL call during the test run.
I think it would be useful... thoughts?
Comment | File | Size | Author |
---|---|---|---|
#31 | drupal-simpletest_xdebug-889338-31.patch | 2.44 KB | heddn |
#19 | drupal-889338-19.patch | 1.48 KB | dawehner |
#17 | interdiff.txt | 1.01 KB | dawehner |
#17 | drupal-889338-17.patch | 1.47 KB | dawehner |
#16 | WebtestBase-xdebug-889338-16.patch | 1.07 KB | das-peter |
Comments
Comment #1
salvisThere'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()?
Comment #2
jhodgdonI got this working by following the procedure linked to above, so you might try that too. I also edited that page with some updated suggestions. I'm not sure any more whether it's necessary to put this into the Simpletest class...
Comment #3
salvisThank you. I haven't been desperate enough yet, but I'll try it when I need to.
Comment #4
jhodgdonI think the handbook page edit mentioned above is sufficient for this to be considered fixed.
Comment #6
yched CreditAttribution: yched commentedReopening.
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 ?
Comment #7
yched CreditAttribution: yched commentedRetitling.
Comment #8
yched CreditAttribution: yched commentedPatch.
Comment #9
das-peter CreditAttribution: das-peter commentedYeah, that's exactly what I need too!
I was using something like this so far in
WebTestBase::curlExec()
:But I can't say if there's a difference between passing the xdebug session as url parameter or as cookie.
Comment #10
dawehnerI tried out the patch but it didn't worked for me. Maybe that's just my setup of xdebug.
Comment #11
dawehnerYched 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.
Comment #12
Damien Tournoud CreditAttribution: Damien Tournoud commentedurl()
is really not meant for that. If you really want to do URL parsing this late in the process, use lower-level functions.Comment #13
das-peter CreditAttribution: das-peter commentedWell 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.
Comment #14
yched CreditAttribution: yched commented#13 works for me too.
Comment #15
yched CreditAttribution: yched commentedI'd suggest this slightly simpler shape for the code though :
Comment #16
das-peter CreditAttribution: das-peter commentedGood idea, and here we go.
Comment #17
dawehnerIt works really great if you have allow three external connections in your debugger. Here is some more explanation and documentation.
Comment #18
damiankloip CreditAttribution: damiankloip commentedMake debuggers work?
Not sure if this should be 'three' - maybe xjm is a good person to ask. I will make the wrong decision here :)
Comment #19
dawehnerJust corrected both.
Comment #20
das-peter CreditAttribution: das-peter commentedThis 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.
Comment #21
jhodgdondas-peter: Sounds like a great idea! There are some notes on http://drupal.org/node/30011 and a troubleshooting section http://drupal.org/troubleshooting that may have info.
if you create a page under Troubleshooting somewhere (I think that would be a good place?) and link here, we can make sure it gets an alias (or you can get someone at the sprint to add it if you don't have permission).
Comment #22
yched CreditAttribution: yched commentedBump - this has been a total life saver for the past month :-)
Comment #23
swentel CreditAttribution: swentel commentedLet's do this!
Comment #24
das-peter CreditAttribution: das-peter commentedI 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.
Comment #25
alexpottCommitted f63db4c and pushed to 8.x. Thanks!
Comment #27
tstoecklerFollow-up (sort of): #2134259: Make the Simpletest XDebug integration work for CLI requests
Comment #28
yched CreditAttribution: yched commentedAm 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)
Comment #29
roderikProbably 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.
Comment #30
heddnLet's see if we can get this backported.
Comment #31
heddnAnd here goes a patch.
Comment #32
frankcarey CreditAttribution: frankcarey commentedThis 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..
Some other notes: I'm using php 5.4.36 in this environment and many tests are failing
Comment #33
frankcarey CreditAttribution: frankcarey commentedComment #34
frankcarey CreditAttribution: frankcarey commentedOK, 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).
Comment #35
frankcarey CreditAttribution: frankcarey commentedComment #38
David_Rothstein CreditAttribution: David_Rothstein commentedTestbot fluke.
Comment #40
stefan.r CreditAttribution: stefan.r commentedComment #41
David_Rothstein CreditAttribution: David_Rothstein commentedLooks like this should help some people, and be harmless for everyone else :)
Committed to 7.x - thanks!