| Q |
A |
| php-code-coverage version |
9.2.10 |
| PHP version |
8.1.2 |
| Driver |
Tested on both PCOV & Xdebug |
| Xdebug version |
3.1.2 |
| Installation Method |
Composer |
| Usage Method |
PHPUnit |
| PHPUnit version |
9.5.13 |
Hi, currently CodeCoverage depends on code execution order.
I created a self contained repo that shows this behavior in https://github.com/Slamdunk/phpunit_codecoverage_bug#readme
Basically, given the following code:
/* 1 */ class A
/* 2 */ {
/* 3 */ public function inArray(): bool
/* 4 */ {
/* 5 */ return \in_array(1, [
/* 6 */ AType::OPT,
/* 7 */ ], true);
/* 8 */ }
/* 9 */ }
- lines 6 and 7 are not considered
LOC if AType was already loaded and parsed before the A is used in the test
- otherwise if
AType is unknown to PHP during inArray call, lines 6 and 7 are considered LOC.
This messes CodeCoverage merging in context like ParaTest where test execution is isolated but not deterministic.
Merging two CC reports coming from different tests run in different processes can result in something like this:

Which doesn't make much sense
I don't know if this library can do much about this, maybe @krakjoe and @derickr could help
Hi, currently CodeCoverage depends on code execution order.
I created a self contained repo that shows this behavior in https://github.com/Slamdunk/phpunit_codecoverage_bug#readme
Basically, given the following code:
LOCifATypewas already loaded and parsed before theAis used in the testATypeis unknown to PHP duringinArraycall, lines 6 and 7 are consideredLOC.This messes CodeCoverage merging in context like ParaTest where test execution is isolated but not deterministic.
Merging two CC reports coming from different tests run in different processes can result in something like this:
Which doesn't make much sense
I don't know if this library can do much about this, maybe @krakjoe and @derickr could help