View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001144 | Xdebug | Code Coverage | public | 2015-04-16 06:42 | 2020-03-12 17:35 |
| Reporter | sebastian | Assigned To | derick | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | duplicate | ||
| Platform | Irrelevant | OS | Irrelevant | OS Version | Irrelevant |
| Product Version | 2.3.2 | ||||
| Summary | 0001144: Add support for filtering of files for code coverage | ||||
| Description | At the moment, Xdebug returns code coverage for all files from which code is executed between xdebug_start_code_coverage() and xdebug_end_code_coverage(). PHP_CodeCoverage takes the raw data that is returned from xdebug_get_code_coverage() and filters it, ie. removes non-whitelisted files when a whilelist is configured or removes blacklisted files when a blacklist is used. The analysis that is performed by Xdebug when XDEBUG_CC_BRANCH_CHECK is set is an expensive operation that is uselessly performed for code that a user of PHPUnit / PHP_CodeCoverage is not interested in (the code of PHPUnit and its dependencies, for instance). It would be beneficial for performance reasons to move the blacklist / whitelist filtering from PHP_CodeCoverage to Xdebug. | ||||
| Tags | No tags attached. | ||||
| Operating System | Irrelevant | ||||
| PHP Version | 5.6.5-5.6.9 | ||||
|
|
By the way: I do not think that it would be a good idea to pass the list of whitelisted or blacklisted files to Xdebug with every call to xdebug_start_code_coverage(). There should be two new functions, xdebug_set_code_coverage_blacklist() and xdebug_set_code_coverage_whitelist(), that can be used to configure the filter. This way the data needs to be passed from userland to Xdebug only once. |
|
|
Is there any plan to work on this ? This would be a huge help when collecting coverage for a functional testsuite. |
|
|
Most definitely. Probably on a plane or something. However, I want to have PHP 7 support sort of working first! |
|
|
Well, to be honest, I'm more interested in getting a usable code coverage reporting on my PHP 5.6 setup (i.e. not taking hours to run my tests with code coverage) than having support for PHP 7 yet (even though it will also be great) :) If I knew C (and had more time as my own OSS projects are already missing attention currently), I would even consider contributing to this. But my C knowledge is approximately equivalent to building a HelloWorld displayed in STDOUT, so I fear it won't be enough... |
|
|
is there any plan to implement this now that PHP 7 support is out ? On a side note, PHPUnit only needs whitelisting support now rather than blacklisting, as PHPUnit 5 removed the blacklisting |
|
|
Derick: Is this still on your TODO? |
|
|
Yes, most definitely! |
|
|
Duplicate of 0001059, which was requested first. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-16 06:42 | sebastian | New Issue | |
| 2015-04-16 06:48 | sebastian | Note Added: 0003071 | |
| 2015-06-25 12:38 | stof | Note Added: 0003130 | |
| 2015-06-25 13:33 | derick | Note Added: 0003131 | |
| 2015-06-25 13:41 | stof | Note Added: 0003136 | |
| 2015-11-22 09:02 | derick | Target Version | => 2.5.0dev |
| 2016-05-12 16:25 | stof | Note Added: 0003602 | |
| 2016-11-28 21:39 | sebastian | Note Added: 0003834 | |
| 2016-11-28 23:36 | derick | Note Added: 0003839 | |
| 2016-11-28 23:36 | derick | Assigned To | => derick |
| 2016-11-28 23:36 | derick | Status | new => confirmed |
| 2016-12-04 18:34 | derick | Target Version | 2.5.0dev => |
| 2016-12-13 21:32 | derick | Note Added: 0004049 | |
| 2016-12-13 21:32 | derick | Status | confirmed => resolved |
| 2016-12-13 21:32 | derick | Resolution | open => duplicate |
| 2020-03-12 17:35 | derick | Category | Feature/Change request => Code Coverage |
