PHPUnit 总是输出“没有执行测试！” 在 MacOS 大苏尔

Question

在尝试运行任何PHPUnit 测试时，我总是No tests executed!在我的 MacOS 机器上收到一条消息。在这台特定机器上重现的一种简单方法是安装 Laravel 的新实例并运行默认测试：

$ composer create-project --prefer-dist laravel/laravel blog
$ cd blog
$ vendor/bin/phpunit

=> No tests executed!

预期的输出将是OK (2 tests, 2 assertions)。

据我所知，这不是 PHPUnit 配置问题，因为默认的 Laravel 代码应该可以工作，其他框架和我尝试的任何代码都会出现同样的问题，不同的 PHPUnit 版本（8.5 和 9.4）也存在同样的问题上面列出的确切步骤会在 Ubuntu VM 以及另一台运行 Catalina 的 Mac 上返回预期的输出。

实际上，我怀疑这不是 PHPUnit 问题，而是 MacOS 问题或PHP 配置问题，以后可能会以其他形式出现在其他工具或项目中。

PHPUnit 曾经在这台机器上工作得很好，但是我实际上已经有几个星期/几个月没有使用它了。自从我上次（成功）在这台 Mac 上使用任何 PHPUnit 以来，唯一改变的是升级到 MacOS Big Sur 并安装（然后卸载）Homebrew。

问题出现 PHPUnit 找不到任何测试套件。在新的 Laravel 安装中运行时vendor/bin/phpunit --testsuite Unit仍然输出No tests executed!，应该输出Ok (1 test, 1 assertion).

所以我的问题是：在全新安装 macOS Big Sur 之前，我还有什么可以尝试解决这个问题的，有没有人遇到同样的问题？

编辑 - 2020 年 12 月 1 日

根据评论中的要求，这是 my phpunit.xml，如上所述，默认 Laravel one。

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <coverage processUncoveredFiles="true">
        <include>
            <directory suffix=".php">./app</directory>
        </include>
    </coverage>
    <php>
        <server name="APP_ENV" value="testing"/>
        <server name="BCRYPT_ROUNDS" value="4"/>
        <server name="CACHE_DRIVER" value="array"/>
        <!-- <server name="DB_CONNECTION" value="sqlite"/> -->
        <!-- <server name="DB_DATABASE" value=":memory:"/> -->
        <server name="MAIL_MAILER" value="array"/>
        <server name="QUEUE_CONNECTION" value="sync"/>
        <server name="SESSION_DRIVER" value="array"/>
        <server name="TELESCOPE_ENABLED" value="false"/>
    </php>
</phpunit>

同样，这应该无关紧要，因为任何配置在这台计算机上返回相同的结果，即使是一些以前已知可以在其他 Mac 和其他操作系统上工作的配置。

使用 artisan 运行测试：

$ php artisan test --testsuite Unit
  No tests executed! 

  Time:   0.01s

的输出vendor/bin/phpunit --list-suites：

$ vendor/bin/phpunit --list-suites
PHPUnit 9.4.4 by Sebastian Bergmann and contributors.

Available test suite(s):
 - Unit
 - Feature

的输出vendor/bin/phpunit -v --testsuite Unit：

$ vendor/bin/phpunit -v --testsuite Unit
PHPUnit 9.4.4 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.3.22-(to be removed in future macOS)
Configuration: /Users/malou/Desktop/blog/phpunit.xml

No tests executed!

注意：/Users/malou/Desktop/blog/phpunit.xml是上面显示的那个。

直接引用文件有效：

$ vendor/bin/phpunit ./tests/Unit
PHPUnit 9.4.4 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.006, Memory: 8.00 MB

OK (1 test, 1 assertion)

编辑 #2 - 2020 年 12 月 1 日

为您提供更多调试信息：

$ php -v
WARNING: PHP is not recommended\nPHP is included in macOS for compatibility with legacy software.\nFuture versions of macOS will not include PHP.
PHP 7.3.22-(to be removed in future macOS) (cli) (built: Oct 30 2020 00:19:11) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.22, Copyright (c) 1998-2018 Zend Technologies
    with Xdebug v2.7.0, Copyright (c) 2002-2019, by Derick Rethans

MacOS 大苏尔 11.0.1

编辑 - 2020 年 12 月 2 日

响应PHPUnit 总是输出“没有执行测试！” 在 MacOS 大苏尔：

我添加了以下内容：

$ composer create-project --prefer-dist laravel/laravel blog
$ cd blog
$ vendor/bin/phpunit

=> No tests executed!

执行时vendor/bin/phpunit：

/Users/malou/Desktop/blog/vendor/phpunit/phpunit/src/TextUI/Command.php:163:
string(0) ""
/Users/malou/Desktop/blog/vendor/phpunit/phpunit/src/TextUI/Command.php:164:
array(1) {
  [0] =>
  string(18) "vendor/bin/phpunit"
}

执行时 vendor/bin/phpunit --testsuite Unit

/Users/malou/Desktop/blog/vendor/phpunit/phpunit/src/TextUI/Command.php:163:
string(0) ""
/Users/malou/Desktop/blog/vendor/phpunit/phpunit/src/TextUI/Command.php:164:
array(3) {
  [0] =>
  string(18) "vendor/bin/phpunit"
  [1] =>
  string(11) "--testsuite"
  [2] =>
  string(4) "Unit"
}

Answer 1

tl;dr Appleversion_compare通过7.3.22-(to be removed in future macOS)在 Big Sur 中命名 PHP来打破僵局。安装另一个版本的 PHP 可以解决这个问题。

我找到了我的问题的答案。这确实是一个 MacOS 问题，与 MacOS Big Sur 中内置的 PHP 版本有关。

经过相当多的调试（在另一个使用 PHPUnit 8 的项目上），我最终在这里：https : //github.com/sebastianbergmann/phpunit/blob/ccbf3962a948112056b0eded6e4c880af4ee3695/src/Util/Configuration.php#L1041-L1055

    private function satisfiesPhpVersion(DOMElement $node): bool
    {
        $phpVersion         = \PHP_VERSION;
        $phpVersionOperator = '>=';

        if ($node->hasAttribute('phpVersion')) {
            $phpVersion = (string) $node->getAttribute('phpVersion');
        }

        if ($node->hasAttribute('phpVersionOperator')) {
            $phpVersionOperator = (string) $node->getAttribute('phpVersionOperator');
        }

        return \version_compare(\PHP_VERSION, $phpVersion, (new VersionComparisonOperator($phpVersionOperator))->asString());
    }

当在PHPUnit的代码之上（并因为这两个最后一行寻找$node->hasAttribute('phpVersion')并$node->hasAttribute('phpVersionOperator')返回false），return语句可以简化为：

version_compare(\PHP_VERSION, \PHP_VERSION, '>=')

现在，由于 MacOS 附带的 PHP 版本在 Big Sur 中被弃用，Apple 将该版本重命名为7.3.22-(to be removed in future macOS). 这就是导致问题的原因，因为上面的代码现在变成：

version_compare("7.3.22-(to be removed in future macOS)", "7.3.22-(to be removed in future macOS)", '>=')

哪个返回 false 而不是 true。

一个简单的测试方法：

$foo = version_compare("7.3.22-(to be removed in future macOS)", "7.3.22-(to be removed in future macOS)", '>=');
var_dump($foo); // bool(false)

$bar = version_compare("7.3.22", "7.3.22", '>=');
var_dump($bar); // bool(true)

这可能是因为，正如官方 PHP 文档中所解释的那样......

该函数首先用点替换 _、- 和 +。在版本字符串中并插入点。在任何非数字之前和之后，例如“4.3.2RC1”变为“4.3.2.RC.1”。然后它从左到右比较零件。如果部分包含特殊版本字符串，则按以下顺序处理：在此列表中找不到的任何字符串 < dev < alpha = a < beta = b < RC = rc < # < pl = p。通过这种方式，不仅可以比较具有不同级别（如“4.1”和“4.1.2”）的版本，还可以比较任何包含开发状态的 PHP 特定版本。

请注意，预发布版本（如 5.3.0-dev）被认为低于其最终发布版本（如 5.3.0）。

... Apple 的命名方案可能被视为低于自己的预发布版本，而不是等同于自己。

因此，修复将覆盖 php 版本，据我所知，这无法在全局范围内完成。使用 Homebrew 安装另一个版本的 PHP 似乎是最简单的解决方案