This PR continue the work @sebastianbergmann made on feature/path-coverage branch.
Includes PRs #398 and #399
Thank you, @Maks3w, for this contribution. It will take a while for me to review this as I am very busy at the moment.
This PR is finish and ready for review. I suggest start for #398 and #399 for make the changeset more tiny.
Yes, of course, I will look at #398 and #399 first. In the meantime it would help me (and others) if you could attach screenshots (maybe from the https://github.com/sebastianbergmann/money/ project) to this issue. Thanks!
These commits show the differences in the output respect master.
Basically I've added the Path data close to the line statistics.
Now I'm playing with executing this in a real library project and I try to make it work. Seems does not recognize the paths but I don't know yet why.
Ah, okay. So for now it's "only" textual. Still a good starting point. Do you also want to implement something like http://derickrethans.nl/images/content/paths-covered-mockup.png?
No sorry, too much. I'm trying to use this data for colorize paths in coveralls.io (using coverage 0/1 value instead hits per line)
I've found a bug related to namespaces. I'll fix it later.
@derickr Any chance for add a whitelist coverage feature to XDebug? I think will save lots of memory because it now tracks all the PHPUnit framework stuff.
@Maks3w http://bugs.xdebug.org/view.php?id=1144 is about pushing the filtering from PHPUnit down to Xdebug.
Path coverage is always shown as 0% for me:
About the HTML Mockup I suggest to do the same I expect to do with coveralls. Turn green or red each line if is covered by a branch or not.
Some tests have too many paths > 4096 which is impossible to print.
@sebastianbergmann I've restored the compatibility with Xdebug < 2.3.2. However I suggest force pathCoverage param from PHPUnit
Please rebase against current master, thanks.
BTW: Thank you for your contributions. I am happy that somebody else works on this code :-) I would be even happier if you would configure your Git client to properly store your name and email with your commits (see https://github.com/sebastianbergmann/phpunit/blob/master/CONTRIBUTING.md#workflow).
Keep up the good work!
I don't understand what do you refer with configure my author data on Git. All my commits have a name and email.
Something is broken. Tests pass but resume is wrong.
Maks3w <email@example.com> is what my Git client shows for your commits. I doubt that "Maks3w" is your real name :-) But no worries.
Workaround Travis Xdebug < 2.3
Clover report. Fill Agregate
Support branch coverage for anonymous functions
At this moment XDebug only tracks anonymous functions inside of methods or functions (not global)
Remove redundant isset && !== null
Prepare for extension. Add test key to line data
Add path coverage to each line
Fix class lookup
Merge pathCovered flag
Fix path coverage
Loop refactor. Early continue loop
@sebastianbergmann Done. Was a problem while skipping path coverage if xdebug didn't support
Re: #400 (comment)
Sure, PHPUnit will need a new configuration option (off by default, IMHO) to control path coverage.
No, Maks3w it's not my real name and my skin is not yellow :-)
I've open sebastianbergmann/phpunit#1937 about path coverage switch on PHPUnit configuration
Reopen as sebastianbergmann/phpunit#1938
I know. I just did the lowest effort so the library still functional.
Do you think is needed to test both scenarios? (path on/off)
Exclude the path information in the HTML output will require duplicate the templates or develop a conditional statement the template.
Will also require duplicate all the test fixtures.
I think 0/0 could be a valid value as has been always in the Clover report (conditionals="0" coveredconditionals="0")
Probably the only thing we could do is paint the values (text and html outputs) with a disabled color (gray)
Restore backward compatibility
Enable pathCoverage by default only when supported
I've rewritten the bc commit. Loops are enough safe for to not depend of the pathCoverage setting value.
Tested with Xdebug 2.4.0beta1
How is this coming along?
Closing #400 and #425 because they have run out-of-sync with master. Please coordinate, @Maks3w and @posey2010, and send a new pull request. Thanks!
@sebastianbergmann I won't spent more time on this for nothing. This PR has been open for 4 months. If you won't merge it why open a new PR
I did not merge it because there were "competing" / conflicting merge requests and I got confused. I hope that a new pull request will be less confusing. Sorry :-(