View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001938 | Xdebug | Code Coverage | public | 2021-01-23 16:01 | 2021-10-04 20:42 |
Reporter | jonnybarnes | Assigned To | derick | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | Apple | OS | macOS | OS Version | 11.1 |
Product Version | 3.0.2 | ||||
Target Version | 3.1dev | Fixed in Version | 3.1.0 | ||
Summary | 0001938: Branches in traits aren’t marked as executed | ||||
Description | I initially thought this was an error in PHPUnit and reported there. They said it was a bug in XDebug itself. This is definitely happening in PHP8 with XDebug 3, it may be happening on older versions as well? If I have a method in a trait, and use that method in a class, and look for code coverage based on branches, I can not get 100% coverage. Here’s a smallest reproducible example: https://github.com/jonnybarnes/trait-path-coverage The paths and branches for the trait are marked as zero coverage:
| ||||
Steps To Reproduce | Import a trait into a class and use its methods. Then measure the path or branch coverage of the codebase. the trait will have 0% path and branch coverage. | ||||
Additional Information | One of the contributors over at PHPUnit thinks it’s a bug in XDebug, they provided this additional information on my bug report from their testing on my minimal case repo:
| ||||
Tags | No tags attached. | ||||
Operating System | |||||
PHP Version | 8.0.0-8.0.4 | ||||
|
I'll have a look in the next week or so. |
|
|
|
I've tested this with 3.1.0beta1 and am wondering if the name-munging is an essential part of the fix or was just a nice-to-have whilst debugging? (i.e. the returnsTrue method in the trait being recorded in the output as returnsTrue{trait-method:bug01938-FooTrait.inc:9-12} php-code-coverage currently has an assumption that they will always be the same. |
|
There is a need for that, because it shows the actual trait method, not the imported version. The same method can be imported by multiple classes, but is actually the same method. I do need to remember this, I think. |
|
Is there any possibility of restoring the actual trait name to the array key alongside the annotation? It's no longer present with 3.1 Before: Currently: It would be really helpful if it could be: I'm working on a patch for php-code-coverage to understand the new data, and stripping off the annotation is fairly trivial but I'd prefer not to have to try and reconstruct the FQCN\Traitname in userland |
|
Can you make a new issue for that? |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-01-23 16:01 | jonnybarnes | New Issue | |
2021-02-18 11:21 | derick | Assigned To | => derick |
2021-02-18 11:21 | derick | Status | new => acknowledged |
2021-02-18 11:21 | derick | Note Added: 0005669 | |
2021-03-17 08:29 | derick | Target Version | => 3.1dev |
2021-08-30 18:33 | derick | Summary | Branches in traist aren’t marked as executed => Branches in traits aren’t marked as executed |
2021-08-30 23:19 | derick | Note Added: 0005997 | |
2021-08-31 16:23 | derick | Status | acknowledged => closed |
2021-08-31 16:23 | derick | Resolution | open => fixed |
2021-08-31 16:23 | derick | Fixed in Version | => 3.1dev |
2021-09-05 16:15 | derick | Fixed in Version | 3.1dev => 3.1.0beta1 |
2021-09-13 15:58 | dvdoug | Note Added: 0006004 | |
2021-10-04 09:32 | derick | Note Added: 0006072 | |
2021-10-04 09:32 | derick | Fixed in Version | 3.1.0beta1 => 3.1.0 |
2021-10-04 19:11 | dvdoug | Note Added: 0006075 | |
2021-10-04 20:42 | derick | Note Added: 0006076 |