mapTestClassNameToCoveredClassName has no effects

[jg-development]

We are using the phpunit.xml class with the option mapTestClassNameToCoveredClassName.
With 4.1.4 it does not have any effect? Is this still an option?

We have the intention to autocover the related Class (and only the related class).
Example:
forceCoversAnnotation=true
mapTestClassNameToCoveredClassName=true

ClassName:
Date
TestName:
DateTest

It seems this is currently not possible?
We decided to implement a getter in the CodeCoverage.php and changed the "getLinesToBeCovered" method. Is a pull request an option?

Greeting Jan

[whatthejeff]

Seems the implementation was removed in 88d167d. @sebastianbergmann, was this intentional?

[sebastianbergmann]

No.

[jg-development]

I did a pull request with the getter ... for the phpunit side a made a different one

[sun]

Hm. Restoring this functionality should be trivial, but:

It looks like mapTestClassNameToCoveredClassName was assuming a literal, direct match between the test class and class under test — which appears to date back to the PHP4 era:

-ThingTest
+Thing

I don't think that is true for most PHP 5.3+ code bases using namespaces, as it assumes:

-My\Space\ThingTest
+My\Space\Thing

I'm aware that there are a few projects that are overloading their test classes into their functional/runtime namespace, but there are a range of sound arguments for not wanting your test code to operate within the same namespace as your functional code.

Instead, you will find plenty of posts on the net that describe the following as a best practice:

{
    "autoload": {
        "psr-4": {
            "My\\Space\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "My\\Tests\\Space\\": "tests/src/",
            "My\\Tests\\Space\\Fixtures\\": "tests/fixtures/"
        }
    }
}

In other words, the modern organization looks like this:

-My\Tests\Space\ThingTest
+My\Space\Thing

…which isn't compatible with the former mapTestClassNameToCoveredClassName implementation.

In addition, I only discovered this issue while searching for documentation and compatibility notes for the case of multiple test suites, which - as of status quo - have to use different filesystem subdirectories and thus have even more differences caused by subnamespaces.

In other words, considering this:

  <testsuites>
    <testsuite name="unit">
      <directory>tests/src/Unit</directory>
    </testsuite>
    <testsuite name="kernel">
      <directory>tests/src/Kernel</directory>
    </testsuite>
  </testsuites>

Each test suite should be isolated and should not discover tests of another suite.

At the same time, all test classes still need to be auto-loadable. Without functional auto-loading, tests will fail to load their base classes.

In turn, still assuming aforementioned composer.json autoload specification, now we have:

-My\Tests\Space\Unit\ThingTest
+My\Space\Thing

[whatthejeff]

Thanks for taking the time to look into this, @sun. I guess we should restore this feature as soon as possible and then start investigating possible avenues for supporting alternate test class => covered class mappings.

[SvenRtbg]

Why does fixing an unintentional change that breaks documented behavior take so long, with pull requests to fix the code being present and being reviewed?

The argument that you probably shouldn't mix the namespaces for production code and tests does not apply to everyone, it is more or less an arbitrary decision, and there already is a solution for that: The @Covers annotation is either being used in these code bases heavily, or coverage is ignored.

This isn't a feature request for easier test-to-code coverage mapping, it's a bug report, and it would be nice if I could stop monkey-patching PHPUnit with a Composer post-install script to work around it.

[sebastianbergmann]

@SvenRtbg Is #261 the pull request you are referring to?

[SvenRtbg]

@sebastianbergmann Yes, I do.
I do notice now that this pull request has some valid comments regarding meta data that haven't been addressed.
Additionally, this fix also affects PHPUnit_Util_Test and PHPUnit_Framework_TestResult, which isn't referenced here as well (and which I haven't found in the PHPUnit issues list).

In other words: I apologize for venting frustrations, we do have a mess here, someone has to clean it up. Maybe I can help, let's see.

[Maks3w]

This feature is expected to be implemented on PHPUnit code base sebastianbergmann/phpunit#1936

This issue could be closed.