This is the first patch to make this actually work again..
Based on your patch in #293298: Add a .patch file for core but I think it should be a separate issue.
This fixes integration during simpletest test runs..
- Connects to the right database to get the test_id and store the coverage results from the correct database. Uses basically the reverse prefix mangling of Simpletest's setUp().
- Uses a hook_form_alter on the result_form to process the coverage logs and displays a message with a link to the report. This could be a bit nicer ;)
- Also missing logging of the coverage inside the test method. Not sure how to do this, a hook in setUp()/tearDown() would be lovely ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | code_coverage.9.patch | 14.16 KB | sun |
| #8 | code_coverage.7.patch | 15.14 KB | sun |
| #4 | code_coverage.4.patch | 13.56 KB | sun |
| #3 | code_coverage.3.patch | 13.5 KB | sun |
| #2 | code_coverage.2.patch | 9.02 KB | sun |
Comments
Comment #1
berdirOh, patch missing...
Comment #2
sunAttached patch
- fixes requirements
- uses already known __FILE__ path info to exclude code_coverage files from recording
- makes ?code_coverage=1 work again
However, SimpleTest integration does not work yet. Nothing is recorded.
Comment #3
sunAttached patch makes SimpleTest code coverage work :)
Comment #4
sunIncorporating latest findings from #741174: Deal with Xdebug inconsistencies
Now this starts to make sense! :)
...and works ;)
Comment #5
berdirYay, sun++
I'll test this soon.
One weird issue I was experiencing with my patch is that tests that run batch don't work. They turn into some kind of weird endless-loop and I have no idea why.
Comment #6
sun@Berdir: Running tests works for me. Obviously, you need to put the following line to the top of bootstrap.inc though:
On the patch:
Missing PHPDoc.
The test ID might be contained in the $form structure as #property - needs to be checked.
code_coverage_process() should have a TRUE|FALSE return value, so we do not output this message if no coverage results are available.
I moved this flag into xdebug.inc, as it should be safe to assume that whenever xdebug.inc is loaded, the core patch has been applied. Overall, however, I'm not sure whether we need this flag. Should be discussed in a follow-up issue.
Changed the random value to not conflict with Simpletest db prefixes first, but afterwards decided to implement Simpletest integration differently. Either way, could use a minimal comment to explain the range.
Apparently, the only documentation about these bit-wise OR'ed flags exists in some slides. Would be helpful if we'd quickly explain them and their effect in an inline comment. Also, the old code/patch mistakenly used || instead of |, so only the value of the first flag was passed, instead of both being OR'ed together.
I'm not sure why we have this try/catch block. The new code should always work and I think it only requires a db-level bootstrap.
I'd like to remove the try/catch block in favor of ensuring/enforcing at least a DRUPAL_BOOTSTRAP_DATABASE in this shutdown function. Some functions that required a full bootstrap have already been eliminated; it should be possible to make it fully db-level bootstrap compliant.
That's also something we could verify in a test.
This db connection target munging could use some more comments, I think.
Let's use $matches[1] as query argument. $coverage_set will be overwritten anyway.
Comment #7
berdirYes, running tests works.
But tests which start a batch don't work for me (for example, cancel a user). The batch doesn't get finished but runs forever until xdebug forcefully finishes it because of recursion.
Comment #8
sunPerformed all changes, except for removing the try/catch block. I'd like to simply remove it and move forward here, but not sure whether that's acceptable.
Comment #9
sunRemoved the try/catch block. Let's improve that in a follow-up patch/issue.
Comment #10
berdirNot sure why you want to remove the try/catch. That's the same as in http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/_drupa....
Sure, in most cases, nothing should go wrong. But are you sure that it can never go wrong? Because if ot does, without that try/catch, you will only have a "Fatal Error: Exception thrown without stracktrace" error that is impossible to debug.
Comment #11
sunThe existing try/catch in _drupal_shutdown_function() is sufficient -- I forgot to mention that I also reverted the change that registered a custom shutdown function back to drupal_register_shutdown_function(). Hence, any exception thrown in our shutdown function will be catched by _drupal_shutdown_function().
I went ahead and committed #9 to master.
Next best step would be to commit a .patch file for bootstrap.inc, I think: #293298: Add a .patch file for core
Comment #12
berdirAh yes, sure then it isn't necessary anymore, I didn't see that :)