ZF-3835: Exception generating code coverage html

Issue Type: Bug Created: 2008-08-03T04:10:10.000+0000 Last Updated: 2008-09-04T00:28:22.000+0000 Status: Resolved Fix version(s): - 1.6.0 (02/Sep/08)

Reporter: Eduardo Marinho (eduardomarinho) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Test_PHPUnit

Related issues: Attachments:


Using PHPUnit 3.2.21

<pre class="literal">
$ phpunit --coverage-html ...
RuntimeException: Could not create and run test suite: Overloading of non-public properties is prohibited in /usr/share/php/PHPUnit/TextUI/Command.php on line 118

$ phpunit --coverage-xml ...
[runs fine]

This exception is being triggered by a property in PHPUnit called __liHtml in Util/Report/Node/File.php


Posted by Matthew Weier O'Phinney (matthew) on 2008-08-03T06:50:13.000+0000

I believe this is due to overloading in the Zend_Test_PHPUnit test suite... and I think it may have been fixed already. Can you please pull from SVN and try running report coverage from there to verify?

Posted by Eduardo Marinho (eduardomarinho) on 2008-08-04T04:12:14.000+0000

Thanks, I forgot to test Svn before reporting.

It stopped throwing the exception but the reports are somehow weird and not what they should be.

For instance:

  • the file names of the pages are being generated incorrectly
  • index.html doesn't contain what it should

I'll come back as soon as I have more information.

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-04T07:23:54.000+0000

Do coverage reports work normally on non-controller test suites (i.e., the ZF test suite, or your own test suites)? If not, then it's an issue with PHPUnit and/or XDebug. Otherwise, I'll consult with Sebastian to see what could be skewing the coverage creation.

Posted by Eduardo Marinho (eduardomarinho) on 2008-08-04T07:23:55.000+0000

When the XDebug trace passes through a view script from Zend_View, the filename resolves to something like

<pre class="literal">

This causes confusion in a PHPUnit function called reducePaths() (PHPUnit/Util/Report.php), which "Reduces the paths by cutting the longest common start path."

So, it will always reduce the path to " " if you use Zend_View and the reports are generated incorrectly.

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-04T07:33:24.000+0000

That's easy, then. In your bootstrap process, call:

<pre class="highlight">

or, if you need short tags, add the following flag when calling phpunit:

<pre class="highlight">
phpunit -d "short_open_tags=on" ...

Both options will disable the stream wrapper, which should fix the coverage reports. (BTW, the stream wrapper will be disabled by default prior to the 1.6.0 final release.)

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-04T07:34:50.000+0000

Issue previously resolved, and phpunit coverage report issue can be solved via settings.

Posted by Eduardo Marinho (eduardomarinho) on 2008-08-04T07:39:16.000+0000

Thanks! Worked perfectly with the stream wrapper turned off.

Posted by Rob Morgan (robsta) on 2008-08-28T01:04:49.000+0000

I've found it works fine when using the Latest Version of Zend_Test_PHPUnit_ControllerTestCase from the Repository. I copied it straight over the version in the 1.6.0RC3 branch.

Posted by Wil Sinclair (wil) on 2008-09-02T10:38:57.000+0000

Updating for the 1.6.0 release.

Posted by Rob Morgan (robsta) on 2008-09-04T00:28:20.000+0000

Hey Guys,

I think this is still an issue in the final release of 1.6.0. I updated the 1.6.0 release with the version from trunk and it appears to be working correctly again.

The only differences are that the trunk version does a 'require_once' of Zend_Registry and the overloading method (__set) is written as:

<pre class="highlight">
if ('_' == substr($name, 0, 1) && ('__' != substr($name, 0, 2))) {

as opposed to:

<pre class="highlight">
if ('_' == substr($name, 0, 1)) {

This seems to make the phpunit coverage reports work correctly.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.