Filesystem-based code coverage targeting

[sebastianbergmann]

This could be as simple as

diff --git a/src/Util/Test.php b/src/Util/Test.php
index 5586c3fd4..605dbebc8 100644
--- a/src/Util/Test.php
+++ b/src/Util/Test.php
@@ -889,8 +889,15 @@ private static function getLinesToBeCoveredOrUsed(string $className, string $met
         }
 
         $codeList = [];
+        $files    = [];
 
         foreach (\array_unique($list) as $element) {
+            if (\file_exists($element)) {
+                $files[] = $element;
+
+                continue;
+            }
+
             if ($classShortcut && \strncmp($element, '::', 2) === 0) {
                 $element = $classShortcut . $element;
             }
@@ -914,7 +921,13 @@ private static function getLinesToBeCoveredOrUsed(string $className, string $met
             );
         }
 
-        return self::resolveReflectionObjectsToLines($codeList);
+        $lines = self::resolveReflectionObjectsToLines($codeList);
+
+        foreach ($files as $file) {
+            $lines[$file] = \range(1, \count(\file($file)));
+        }
+
+        return $lines;
     }
 
     /**

[sebastianbergmann]

The above would only work for absolute paths. We need to support relative paths, too, but we do not know what the base is.

[bancer]

Some PHP frameworks include files without PHP classes such as ones where PHP is mixed with HTML. The coverage is generated well without @covers annotation when testing a controller class. But when @covers is used then the coverage for such files is missing. Maybe there is any other way to include them except the fix that is posted above?

In our case @covers improves the performance of generating the coverage report by 25% percent and we would like to use this annotation but the missing coverage for the plain PHP files makes it questionable.

We need to support relative paths, too, but we do not know what the base is.

As a possible solution I would like to suggest to add is_base="true" parameter to the whitelisted directory in the configuration file that would be used as the base (and to allow only one directory to be the base), f.ex.:

<filter>
  <whitelist>
    <directory suffix=".php" is_base="true">src</directory>
    <directory suffix=".ctp">src/Template</directory>
  </whitelist>
</filter>

[SamMousa]

I'm open to implementing this, have a local version working based on a more recent version than the example above.
I will need some input on a few points:

1. Match a new pattern in Mapper::stringToCodeUnits, I'm thinking of a more explicit pattern like file:/src/file.php, but just implicitly based on the presence of an extension could also work.

2. Every type of code unit has a class and a sort of checker that is never used in the code, like ClassMethodUnit::isClassMethod(), should I add just copy the structure and implement a FileUnit::isFile()?

3. I implemented it locally by just returning a very large range ie range(1, 100000), this reduces the need to read the file twice. Would this be okay or do you prefer actually parsing the file for number of lines?

4. Relative paths relative to the file of the annotations can be implemented pretty simply, since we know the class in which @covers is used. I'm not sure this is very valuable though.

5. Relative paths relative to the some application root will require a way of injecting or retrieving configuration. I propose not implementing this in the first draft. People running in containers will be able to get most of the benefits using absolute paths, and adding support for relative paths later won't break anyone's setup.

[riabiy-denis]

Another case, where this would be useful, is testing closure-based routes for some Nova components.
Simple ones are quite easy to define in one file, but then PhpStorm navigation is broken. Having ability to set path would resolve the issue.