Allow attributes for code coverage targeting to also be used on the test method level (instead of only on the test class level) about phpunit HOT 4 CLOSED

Sure, my "but people are using this" response was mostly a frustrated "this was closed without any discussion WTF" response. I'm still pretty frustrated because people in the original issue are requesting it, I'm requesting it, seems like there's interest so maybe would could have at least discussed before closing it.

Frustrating aside, to your question, as mentioned in the summary its useful for explicitly flagging what the test method is intended to test. This has some benefits

1. You can see what code it testing your method when reviewing a method even if the call is indirect.
2. You can quickly link back to the code you're testing in your IDE.
3. Your coverage test doubles to make sure you're not trying to cover code that no longer exists. This may seem uncommon because your test should be calling the method you're testing. However this has flagged dead tests for me quite a few times and the amount of time I've spent tracking broken tests on projects to code that hasn't existed for multiple versions tells me this is actually valuable.
4. Reports can be cleaner. If you have a class that has two methods and a couple hundred provided arguments, if you have any interaction between the methods you get these crazy big reports where you get cross coverage that makes detailed reports kinda useless. A specific XSS class comes to mind which has a test and a filtering method and thousands of test cases. The test is better by being able to split the tests and the report is exponentially smaller by being able to assign the coverage.

I think this generally starts being useful in more complicated systems where there's "magic" happening. Drupal has a lot of this but I really appreciate this when writing tests for Laravel which more people here might be familiar with. Here's an overly simplified test that would test a Controller in Laravel:

<?php

use Illuminate\Foundation\Testing\TestCase;

/**
 * @coversDefaultClass \App\Http\Controllers\ContactController
 */
class FooControllerTest extends TestCase {
    /**
     * @covers ::index
     */
    public function testIndex() {
        $response = $this->get('/api/v1/foo');
        // Assertions...
    }
}
?>

Without the @Covers to explicitly link there is no way to see what this is covering. With it, my IDE shows this code in the usage list for index, I can quickly navigate to the code being tested though the docblock, the method doesn't show up as "unused", and if the method name changes but it passes (maybe in a unexpected way) the coverage report catches it and forces a review.

Testing controllers with coverage is pretty useful but a little weird but this sort of indirect call in testing can happen for a lot of reasons. Testing container interactions, code running in events, testing queue systems, etc.

So yeah, I think in an ideal world this wouldn't be useful. But in reality I find it incredibly useful.

from phpunit.

To me, allowing attributes for code coverage targeting to also be used on the test method level does not make sense.

from phpunit.

OK but... Drupal uses it and ever project I work on does so... other people are using it.

from phpunit.

@neclimdul maybe you could elaborate when it is useful, technically. Claiming "other people are using it" is not really an argument. Millions of flies can't be wrong, right?

I have never used it (maybe it would be useful in some projects I worked decade ago, but they had no test at all). I believe if you are following SRP then coverage on a class level is enough.

from phpunit.