Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for unexecuted covered or used code is too strict #420

Closed
sebastianbergmann opened this issue Feb 8, 2016 · 3 comments
Closed

Check for unexecuted covered or used code is too strict #420

sebastianbergmann opened this issue Feb 8, 2016 · 3 comments

Comments

@sebastianbergmann
Copy link
Owner

The implementation of #234 in 168eaf4 is too strict. When @covers Foo::bar is used then the current implementation expects all lines of code in Foo::bar() to be executed when instead it should only expect one line of code in Foo::bar() to be executed.

@sebastianbergmann
Copy link
Owner Author

I started to work on this in 1cedd8b. This should work unless the sourcecode file of the code unit to be covered or used has not been loaded at all. In that case https://github.com/sebastianbergmann/code-unit-reverse-lookup does not yield a useful result.

All things considered, this approach is rather stupid. PHPUnit turns code unit information (@covers class::method) into filename and line numbers information which PHP_CodeCoverage then tries to convert back into code unit information.

It might be best for PHPUnit to pass lists of code units (from @covers and @uses annotations) to PHP_CodeCoverage and consistently use that information inside PHP_CodeCoverage.

@sebastianbergmann
Copy link
Owner Author

@belanur We missed the opportunity of the PHPUnit Code Sprint to discuss this. @spriebsch just reminded me that this still does not work. Will try to look into it but any help appreciated.

sebastianbergmann added a commit that referenced this issue Apr 10, 2017
@sebastianbergmann
Copy link
Owner Author

Updated the initial work done in March 2016 to the state of master in April 2017 in 88653cb.

I will probably do what I thought about in #420 (comment), though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant