Missing code coverage schema prevents results being displayed.

[cmkhpacknet]

The schema which should be available at:
http://schema.phpunit.de/coverage/1.0
or
https://schema.phpunit.de/coverage/1.0
is currently returning a 404 message.

While I understand this is a missing file issue and not a bug as such, would it be possible to include a fixed version of this in phpdox to prevent this in future.

[theseer]

I'm not sure I understand your problem: How would a 404 with regards to something in PHPUnit should affect phpDox? I'm not aware of any code in phpDox that would verify the coverage report based on its schema.

[cmkhpacknet]

My apologise, let me re-phrase.
In reference to #333 - both the http and https versions of that file are currently missing / returning a 404. If you click on either of the links above, you'll see that they don't link to the correct files.

Because the schema is not available, phpdox cannot process the phpunit code coverage xml file. The error message reported in #333 is returned. Is there any way the schema can be ignored if it simply can't be found ?

Thanks for your time.

[theseer]

Okay, getting clearer but still confused ;)

Let me try to add a short explanation to XML and namespaces, maybe afterwards you understand my confusion:

An XML namespace is merely a string in form of an URI. Technically, "foo:bar" is a valid URI as the regex basically only requires a : to be included and thus is also a perfectly valid namespace identifier. It is of course a common practice to use (HTTP) URLs as a namespace identifier rather than using arbitrary URIs.

Those URLs can of course resolve to an actual website - most common would actually be some sort of human readable documentation - but it neither has to resolve at all nor does it have to provide anything that can be used for (automated) processing - like an XSD or DTD - there.

That being said, phpDox merely looks at the namespace identifier to determine whether or not the file found can be a coverage file. It doesn't validate the actual document structure or anything. It doesn't care (or, technically speaking, know) the identifier is an URL and thus never even tries to access it.

Of course that doesn't fix your problem of not having coverage information rendered. Can you provide me with some more details as to what is actually happing, how you generated the coverage, the relevant config xml fragments?

[cmkhpacknet]

I'm using CodeCeption to generate the xml file for phpdox :

./vendor/bin/codecept run --coverage --phpunit-xml=index.xml

From phpdox.xml :

<source type=phpunit>
<coverage path="${basedir}/build/codeception/coverage" />
</source>

I'm using the phpdox.xml file generated by :

phpdox --skel

I have phploc, phpcs, phpmd and Git enrichers all working with phpdox, so only the phpUnit information isn't showing.

When I run phpdox, for the generation process I get :

[25.07.2019 - 08:16:45] Starting generator
[25.07.2019 - 08:16:45] Loading enrichers
[25.07.2019 - 08:16:45] Enricher PHPLoc xml initialized successfully
[25.07.2019 - 08:16:45] Enricher GIT information initialized successfully
[25.07.2019 - 08:16:45] Enricher PHPCS XML initialized successfully
[25.07.2019 - 08:16:45] Enricher PHPMessDetector XML initialized successfully
[25.07.2019 - 08:16:45] Exception while initializing enricher phpunit:

    Wrong namspace - not a PHPUnit code coverage file

[25.07.2019 - 08:16:45] Enricher Build Information initialized successfully
[25.07.2019 - 08:16:45] Starting event loop.

..................................................	[50]
..................................................	[100]
..................................................	[150]
..................................................	[200]
..................................................	[250]
...........................................       	[293]

[25.07.2019 - 08:16:54] Generator process completed
[25.07.2019 - 08:16:54] Processing project 'Metis 2' completed.


Time: 8.92 seconds, Memory: 10.00 MB

phpdox version :
phpDox 0.12.0-dev - Copyright (C) 2010 - 2019 by Arne Blankerts and Contributors

[theseer]

Ah, now we're talking :)

I'm not using code ception and thus can only guess what the invocation you showed does.

I have no idea what type of coverage codeception creates when --coverage is being supplied or if it somehow affects what PHPUnit does for coverage.

If the index.xml is a PHPUnit configuration xml file, for phpDox to get coverage information, there needs to be an entry that produces PHPUnit's own XML Coverage report (e.g. <log type="coverage-xml" target="build/codeception/coverage" /> and not only clover or html.

Can you verify that? What version of PHPUnit are you using?

[cmkhpacknet]

I'm using :
Codeception PHP Testing Framework v3.0.3
Powered by PHPUnit 8.2.5 by Sebastian Bergmann and contributors.

From the Codeception manual :
https://codeception.com/docs/reference/Commands

--phpunit-xml Generate PhpUnit XML Log (default: "phpunit-report.xml")
This is the one I'm using.

However I've just noticed :
--coverage-phpunit Generate CodeCoverage PHPUnit report in file (default: "coverage-phpunit")

I'm going to see what that produces and see if that's what I should be using.

[cmkhpacknet]

Using the --coverage-phpunit flag, phpdox seems to be happy processing the XML files produced. However, while I now have Coverage sections showing up on the individual classes, they are showing no code coverage on classes I know have code coverage. This is definite progress though.

[25.07.2019 - 13:42:52] Collector process completed

[25.07.2019 - 13:42:52] Starting generator
[25.07.2019 - 13:42:52] Loading enrichers
[25.07.2019 - 13:42:52] Enricher PHPLoc xml initialized successfully
[25.07.2019 - 13:42:52] Enricher GIT information initialized successfully
[25.07.2019 - 13:42:52] Enricher PHPCS XML initialized successfully
[25.07.2019 - 13:42:52] Enricher PHPMessDetector XML initialized successfully
[25.07.2019 - 13:42:52] Enricher PHPUnit Coverage XML initialized successfully
[25.07.2019 - 13:42:52] Enricher Build Information initialized successfully
[25.07.2019 - 13:42:52] Starting event loop.

..................................................	[50]
..................................................	[100]
..................................................	[150]
..................................................	[200]
..................................................	[250]
...........................................       	[293]

[25.07.2019 - 13:43:02] Generator process completed
[25.07.2019 - 13:43:02] Processing project 'Metis 2' completed.


Time: 10.18 seconds, Memory: 10.00 MB

It seems my initial issue raised is not the actual problem, so I understand if this ticket is closed.
Thanks for your help, it's much appreciated. phpdox is helping us greatly on our project. :)

[theseer]

That sounds like a path mapping problem. I was under the assumption that i fixed all of them ;-) I'll check back when I'm at a computer. Am Donnerstag, 25. Juli 2019 schrieb cmkhpacknet:

…

I'm using : Codeception PHP Testing Framework v3.0.3 Powered by PHPUnit 8.2.5 by Sebastian Bergmann and contributors. From the Codeception manual : https://codeception.com/docs/reference/Commands --phpunit-xml Generate PhpUnit XML Log (default: "phpunit-report.xml") This is the one I'm using. However I've just noticed : --coverage-phpunit Generate CodeCoverage PHPUnit report in file (default: "coverage-phpunit") I'm going to see what that produces and see if that's what I should be using. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #367 (comment)

-- Gesendet von meinem Sailfish-Gerät.

[cmkhpacknet]

I have tried using PHPUnit (6.5.14) instead of CodeCeption and that has solved this issue. The XML produced is correctly read by phpdox and I'm seeing the code coverage results show in the class and source code pages.

[theseer]

Given you previously used PHPUnit 8 via CodeCeption, it would be rather interesting to see if things work as you want when you use PHPUnit 8 rather than only the old 6.5.14.

[theseer]

Considering this case closed :)

[cmkhpacknet]

Thanks for your help on this. Much appreciated. :)