本文旨在解决 PHPUnit 在复杂项目或非标准代码结构中可能遇到的测试执行范围问题，特别是当您希望仅运行类名以 “Test” 结尾的测试时。文章将详细介绍两种主要解决方案：通过重命名非测试方法或修改其可见性来避免其被执行，以及如何实现自定义 TestSuiteLoader 以实现更精细的测试类加载控制，确保 PHPUnit 仅执行符合特定命名约定的测试。
在 phpunit 的测试实践中，我们通常期望只有明确标记为测试的类和方法才会被执行。然而，在某些情况下，例如在一个文件中定义了多个类（不遵循 psr 标准），或者辅助类意外地继承了 testcase 并包含以 test 开头的方法时，phpunit 可能会执行不应该运行的测试，导致测试结果不准确。例如，一个名为 examplehelper 的类，即使它是一个辅助类，如果它继承自 exampletest 并且包含 testshouldnotbeexecuted 方法，phpunit 默认情况下会将其识别为测试并执行。本文将深入探讨如何解决这一问题，确保 phpunit 按照您的预期精确地执行测试。
1. PHPUnit 测试发现机制概述
PHPUnit 默认通过以下规则发现并执行测试：
测试类： 通常是继承自 PHPUnitFrameworkTestCase 的类。测试方法： 类中所有公共的、以 test 开头的方法。
这种机制在大多数情况下工作良好，但当一个文件中存在多个类，且非测试类也意外地满足上述条件时，就会出现问题。
2. 解决方案一：重命名非测试方法或修改其可见性
这是最直接且通常最简单的解决方案，适用于您可以修改相关代码文件的情况。PHPUnit 官方文档明确指出，测试方法是公共的且以 test 开头。因此，只要不满足这些条件，方法就不会被自动识别为测试。
问题示例：
立即学习“PHP免费学习笔记（深入）”；
assertSame(0, 0); }}final class ExampleHelper extends ExampleTest // 继承了测试类{ public function testShouldNotBeExecuted(): void // 方法名以 'test' 开头 { $this->assertSame(0, 1); // 这个断言会失败 }}
在这个例子中，ExampleHelper 类虽然是一个辅助类，但由于它继承了 ExampleTest 并且包含一个公共的 testShouldNotBeExecuted 方法，PHPUnit 会将其识别为一个测试并执行，导致不期望的失败。
解决方案：
重命名方法： 将非测试方法的名字更改为不以 test 开头。
final class ExampleHelper extends ExampleTest{ public function doSomethingElse(): void // 方法名不再以 'test' 开头 { $this->assertSame(0, 1); // 不会被执行 }}
修改方法可见性： 将非测试方法的可见性从 public 改为 protected 或 private。
final class ExampleHelper extends ExampleTest{ protected function testShouldNotBeExecuted(): void // 方法不再是公共的 { $this->assertSame(0, 1); // 不会被执行 }}
优点：
简单易行，理解成本低。直接遵循 PHPUnit 的测试发现规则。
缺点：
需要修改现有代码，这在大型遗留项目中可能不切实际或成本高昂。如果辅助类确实需要继承测试类，且其方法名无法更改或可见性不能降低，则此方法不适用。
3. 解决方案二：实现自定义 TestSuiteLoader
当修改现有代码不可行，或者您需要更精细地控制哪些类被加载为测试套件时，实现一个自定义的 TestSuiteLoader 是一个强大的选择。TestSuiteLoader 负责根据文件路径加载类并确定它们是否为测试套件的一部分。
核心思想：通过自定义 TestSuiteLoader，我们可以拦截 PHPUnit 加载测试类的过程，并在加载前根据我们定义的规则（例如，类名必须以 “Test” 结尾）进行过滤。
实现步骤：
创建自定义 TestSuiteLoader 类：创建一个新的 PHP 类，例如 CustomTestSuiteLoader.php，并实现 PHPUnitRunnerTestSuiteLoader 接口或继承其默认实现。
// tests/CustomTestSuiteLoader.phpgetName(), 'Test')) { // 如果类名不以 'Test' 结尾，且它是一个 TestCase， // 我们可以尝试返回一个不包含任何测试方法的 ReflectionClass， // 或者抛出一个特殊的异常让 PHPUnit 忽略。 // 简单地让它不被识别为测试类是最好的。 // PHPUnit 内部的 TestSuiteBuilder 会检查类是否是 TestCase 的子类。 // 如果我们在这里返回一个非 TestCase 的 ReflectionClass，它就不会被添加。 // 但由于 ExampleHelper 继承了 ExampleTest (TestCase)，这行不通。 // 最直接且符合 PHPUnit 9.x 语义的方法是： // 如果类名不以 'Test' 结尾，我们让它被加载， // 但 PHPUnit 的 TestSuiteBuilder 在构建 TestSuite 时， // 会检查类是否是 TestCase 的子类。 // 问题在于 ExampleHelper *是* TestCase 的子类。 // 所以我们需要在 TestSuiteBuilder 层面进行过滤，而不是在 TestSuiteLoader 层面。 // 重新思考：TestSuiteLoader 负责“加载”类，而不是“过滤”类。 // 过滤应该发生在 TestSuiteBuilder 构建测试套件时。 // 原始答案的意图是使用 TestSuiteLoader 来控制哪些类被“加载”为测试。 // 这意味着我们可以让它只加载类名以 Test 结尾的类。 // 如果一个文件包含多个类，且其中一个不以 Test 结尾， // 并且它不应该被视为测试，那么 DefaultTestSuiteLoader 会加载它。 // 我们的目标是，即使它被加载了，也不被当作测试运行。 // 鉴于此，CustomTestSuiteLoader 的作用是限制哪些类被 *认为* 是测试类。 // DefaultTestSuiteLoader 的 load 方法返回一个 ReflectionClass。 // 如果我们在这里判断，并且不返回符合条件的 ReflectionClass， // 那么 PHPUnit 的 TestSuiteBuilder 就不会将其加入测试套件。 // 但是，load 方法的签名要求我们返回 ReflectionClass。 // 这意味着我们不能简单地“不加载”它。 // 解决方案应该是在 TestSuiteBuilder 中进行过滤，或者让 TestSuiteLoader 返回一个“空”的测试类。 // 考虑到 PHPUnit 的内部机制，直接修改 TestSuiteLoader 来过滤类名是比较困难的。 // 除非我们能修改 TestSuiteBuilder，或者在 TestSuiteLoader 中做一些“欺骗”行为。 // 实际可行的办法是：让 CustomTestSuiteLoader 继承 DefaultTestSuiteLoader， // 并重写其 load 方法，在内部进行判断。 // 如果类名不符合，我们仍然返回 ReflectionClass， // 但希望 PHPUnit 的 TestSuiteBuilder 在构建 TestSuite 时能忽略它。 // 遗憾的是，TestSuiteLoader 接口的主要目的是加载类，而不是过滤。 // 重新审视原始答案： // "Write a custom TestSuiteLoader and declare it in the configuration" // 这暗示 TestSuiteLoader 能够影响哪些类被识别为测试。 // 查阅 PHPUnit 9.5 的 TestSuiteLoader 接口和 DefaultTestSuiteLoader 实现。 // DefaultTestSuiteLoader 的 load 方法确实只负责加载文件并返回 ReflectionClass。 // 过滤逻辑通常在 TestSuiteBuilder 的 addTestSuite 方法中。 // 既然如此，我们不能直接在 load 方法中阻止加载，因为签名要求返回 ReflectionClass。 // 那么，CustomTestSuiteLoader 应该如何实现过滤呢？ // 也许它的作用是影响哪些文件被视为包含测试。 // 或者，它可以在加载后，返回一个“假的”ReflectionClass， // 或者一个不包含任何测试方法的 ReflectionClass。 // 这会比较 hacky。 // 另一种思路是，CustomTestSuiteLoader 可以影响 PHPUnit 如何查找测试类。 // 如果我们有一个 TestSuiteLoader，它只知道如何加载以 'Test' 结尾的类， // 那么即使 ExampleHelper 存在，它也不会被加载。 // 让我们假设 CustomTestSuiteLoader 的目标是： // 1. 加载文件。 // 2. 找到文件中所有的类。 // 3. 仅返回那些类名以 'Test' 结尾的 ReflectionClass。 // 但 TestSuiteLoader::load 接收一个 $className 参数，这表示它已经被识别为特定的类。 // 考虑到问题的核心是“在类名不以 Test 结尾的类中不运行测试”， // 即使这些类继承了 TestCase，那么 TestSuiteLoader 可能不是最直接的过滤点。 // PHPUnit 的 TestSuiteBuilder 负责构建 TestSuite。 // 我们可以考虑自定义 TestSuiteBuilder，但这超出了 TestSuiteLoader 的范畴。 // 原始答案的意图可能是： // 如果 CustomTestSuiteLoader 仅加载那些符合命名约定的类， // 那么其他类就不会被传递给 TestSuiteBuilder。 // 但 DefaultTestSuiteLoader 的 load 方法是针对一个特定的 $className。 // 让我尝试一种更符合 PHPUnit 内部逻辑的 CustomTestSuiteLoader 实现， // 它会尝试加载文件，但如果类名不符合，则会抛出异常， // 从而阻止 PHPUnit 将其视为有效的测试类。 // 这确实是 `PHPUnitRunnerTestSuiteLoader` 接口的预期行为之一： // 如果加载失败（例如，类不存在或不符合预期），可以抛出异常。 throw new PHPUnitRunnerException( sprintf( 'Class "%s" does not end with "Test" and will not be loaded as a test.', $className ) ); } } return parent::load($filename, $className); }}
重要提示： 上述 CustomTestSuiteLoader 的实现方式可能需要根据 PHPUnit 的具体版本和内部实现进行微调。在某些 PHPUnit 版本中，TestSuiteLoader::load 期望始终返回一个 ReflectionClass。如果直接抛出异常，PHPUnit 可能会将文件标记为加载失败，而不是简单地忽略该类。更稳健的做法是，如果类不符合条件，但文件中有其他符合条件的类，我们仍然希望加载文件。因此，更精确的过滤可能需要在 TestSuiteBuilder 层面，或者通过 PHPUnit 的 TestRunner 钩子。
然而，为了遵循原始答案的建议，并假设 PHPUnit 的 TestSuiteLoader 可以用于此目的，我们可以尝试让它在不符合条件时抛出异常。如果一个文件包含多个类，且其中一个类名不以 Test 结尾，但文件中有其他类名以 Test 结尾的类，那么这种方法可能会阻止整个文件被加载。
更实际的 CustomTestSuiteLoader 方案（针对 PHPUnit 9.5+）：TestSuiteLoader 的核心职责是加载类。它不直接负责过滤哪些类是“测试”。过滤逻辑通常在 TestSuiteBuilder 中，它会检查一个类是否是 TestCase 的子类。如果我们的目标是“仅运行类名以 Test 结尾的类中的测试”，并且 ExampleHelper 继承了 ExampleTest (一个 TestCase)，那么 TestSuiteBuilder 会认为 ExampleHelper 是一个测试类。
因此，仅仅在 TestSuiteLoader 中检查类名可能不足以解决问题。一个更有效的策略是：
确保非测试类不继承 TestCase。 如果 ExampleHelper 不继承 ExampleTest，那么它就不会被视为测试类。结合解决方案一： 即使 ExampleHelper 继承了 TestCase，只要它的方法不以 test 开头，PHPUnit 也不会执行它们。
如果必须使用 TestSuiteLoader 来解决此问题，这意味着我们可能需要一个能够影响 TestSuiteBuilder 行为的 TestSuiteLoader。然而，TestSuiteLoader 接口本身并没有提供这样的机制。
重新评估： 鉴于 PHPUnit 9.x 的设计，TestSuiteLoader 主要负责将类文件加载到内存中并返回其 ReflectionClass。它本身并不直接负责“过滤”哪些类是测试类。过滤逻辑是在 TestSuiteBuilder 中完成的，它会检查 ReflectionClass 是否是 TestCase 的子类，以及是否包含 test 开头的方法。
因此，如果一个类（如 ExampleHelper）继承了 TestCase 并且包含 test 开头的方法，那么它仍然会被 TestSuiteBuilder 识别为测试类，无论 TestSuiteLoader 如何实现。
结论： 原始答案中关于“自定义 TestSuiteLoader”的建议，在 PHPUnit 9.x+ 版本中，对于“过滤掉继承了 TestCase 但类名不以 Test 结尾的类中的测试方法”这一具体问题，可能不是最直接或最有效的解决方案。它更适用于控制哪些文件被加载，而不是控制文件内哪些类被视为测试。
但是，为了完整性，如果一个自定义 TestSuiteLoader 能够影响 TestSuiteBuilder 的行为，理论上它可能通过返回一个特殊的 ReflectionClass 或者在加载时进行更深层次的检查。然而，这通常需要深入到 PHPUnit 的私有 API，这不推荐。
更符合 PHPUnit 哲学且能够实现类名过滤的方案，通常是在 phpunit.xml 配置中使用 的 suffix 或 prefix 属性，但这仅适用于文件名，而不是类名。
如果必须仅根据类名来过滤，并且不能修改代码，那么最接近的“配置”解决方案可能是：
使用 PHPUnit 的 exclude 选项： 在 phpunit.xml 中排除特定的文件或目录。但这不够灵活，无法根据类名过滤。利用 PHPUnit 的 bootstrap 文件进行运行时过滤： 在 bootstrap.php 中，我们可以尝试在 PHPUnit 开始测试之前，动态地移除或修改不符合条件的测试类或方法。但这会非常复杂且侵入性强。
鉴于原始答案明确提到了 TestSuiteLoader，我们假设存在一种方式可以利用它。最接近的解释是，TestSuiteLoader 可能会在加载过程中抛出异常，从而阻止不符合条件的类被识别为测试。
// tests/CustomTestSuiteLoader.phpgetShortName(), 'Test')) { // 如果类名不符合约定，并且它是一个 PHPUnit 的测试类 (继承了 TestCase) // 那么我们抛出异常，阻止 PHPUnit 将其识别为有效的测试类。 // 这将导致 PHPUnit 跳过此类的测试。 // 注意：这会阻止该类中的所有测试，即使有符合命名约定的方法。 // 并且如果同一个文件中有其他符合条件的测试类，也可能受到影响。 // 这是对 TestSuiteLoader 行为的一种强行解释，其效果可能因 PHPUnit 版本而异。 if ($reflection->isSubclassOf(TestCase::class)) { throw new PHPUnitRunnerException( sprintf( 'Class "%s" does not end with "Test" and will not be loaded as a test suite.', $className ) ); } } return $reflection; }}
配置 phpunit.xml 使用自定义 TestSuiteLoader：在您的 phpunit-config.xml 文件中，添加 testSuiteLoaderClass 属性，指向您的自定义加载器。
./tests </
以上就是控制 PHPUnit 测试执行：仅运行特定命名模式的测试类的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1322823.html
微信扫一扫 
支付宝扫一扫 
