Verifying correctness of @covers tags

[JeroenDeDauw]

In my projects I have a ci command that runs PHPUnit and some other stuff. This is also what TravisCI runs. The only difference is that TravisCI also runs code coverage generation (via PHPUnit) afterwards. This means the TravisCI build can fail due to a typo in an @Covers tag, which will only show up when running coverage generation.

One fix is to execute phpunit --coverage-text=/dev/null. That will then fail as desired if a @Covers tag got messed up. That however slows the command down significantly. On one project from ~850ms to ~18s.

Is there a way to have PHPUnit fail when a @Covers tag is wrong without running the actual coverage report generation? If not, consider this a feature request.

Currently using PHPUnit 4.7.3, though I've been running into this for years.

[sebastianbergmann]

I agree that this functionality is desirable but it does not belong in PHPUnit but rather a separate tool, for instance implemented as a sniff for PHP_CodeSniffer.

[JeroenDeDauw]

I thought the @Covers tags where a PHPUnit thing. Is there anything else that uses them?

My main issue here is that PHPUnit is the thing erroring out and causing my TravisCI builds to fail. If you say the correctness os the tags is not something for PHPUnit to check, then to me it seems that this erroring out should also not happen. If such a change is made, then the PHPCS route makes more sense to me.

[sebastianbergmann]

The @covers annotation is a PHPUnit thing, yes. But it is only looked at when code coverage data is collected and processed. You are asking for doing something with the annotation without collecting and processing code coverage data. That does not belong in PHPUnit, IMHO.

[JeroenDeDauw]

What I want is to have the possibility to generate coverage on a CI service and at the same time not have PHPUnit fail in such a way that I cannot detect beforehand without using an additional tool. What I originally asked for is indeed to add a new kind of check that can be run without collecting coverage data. I understand your point of how this is out of scope. Which is why I am now suggesting to have an option that makes the coverage generation not cause an error when it encounters an invalid @Covers tag.

[sebastianbergmann]

Then please open a new ticket for that. Thanks.

[JeroenDeDauw]

Sure. #1760

[oradwell]

@JeroenDeDauw We run our coverage report daily which takes 30 mins to run. Here is a CLI tool I made for validating @covers tags: ockcyp/covers-validator

[JeroenDeDauw]

Thanks a lot @ockcyp, I'll have a go at using your tool :)