performance - 标记单元测试

Question

我正在开发一个具有可靠单元测试覆盖率的 PHP 项目。

我注意到，上次，我使用 unit-tests Command-Line Test Runner' --filter命令进行了非常棘手的操作。

以下是官方文档中对该命令的解释：

- 筛选

仅运行名称与给定模式匹配的测试。模式可以是单个测试的名称，也可以是匹配多个测试名称的正则表达式。

我经常使用它，因为有时只运行整个测试库中的单个测试套件或测试用例会变得非常有用。

我想知道这是否是好习惯？

我听说有时在您的持续集成机器上运行整个测试套件是一种很好的做法，如果您确定自己只修改了一个组件并且100% 有信心，它不会使其他组件的单元失败-测试。你怎么看待这件事？

前段时间我认为我们不应该太关心运行所有单元测试的整个套件所需的时间，但是当您有非常复杂的业务逻辑和单元测试时 - 这可能会花费大量时间。

我明白，“真正的”单元测试不应该与数据库交互，使用模拟/存根对象，我同意这一点。但有时，使用 DB 固定装置进行测试更容易（更便宜）。

请给我一些建议，如何解决这个问题？

score 1 · Accepted Answer

好的单元测试应该：

有明确的方法名称和变量名称作为文档
快跑。这对于复杂业务逻辑的测试也是可能的。测试应该以大约 0.1 秒的平均时间运行。
在一种测试方法中准确测试一件事
不与文件系统、电子邮件、数据库、Web 服务和其他所有外部资源集成。您可以创建单独的数据库集成测试来测试您的数据库交互。大多数情况下，这些测试会比你的单元测试慢。我将集成测试放在一个单独的项目中，并且仅在处理集成代码时才运行它们。我还在 CI 服务器上的所有构建中运行它们。
彼此完全隔离。当您的测试相互依赖时，您无法通过阅读哪些测试失败来了解您的问题。您可能需要调试才能找到问题。独立测试将为您节省大量时间。

就个人而言，我在测试中不使用类别名称。我每个应用程序使用 2 个测试项目。一种用于单元测试，一种用于集成测试和较慢的测试。

反应：

“但有时，使用 DB 固定装置进行测试更容易（更便宜）。”

当你的代码写得好时，它会更容易模拟。我不知道 Php 中的 mocking 框架，但我在其他语言中使用它们可以节省我很多时间。先写测试再写代码可能会帮助你设计更容易测试的代码。

就我个人而言，我学会了更好地测试

score 1 · Accepted Answer

我经常使用它，因为有时只运行整个测试库中的单个测试套件或测试用例会变得非常有用。

我想知道这是否是好习惯？

当然，只要您偶尔运行全套单元测试（通过 CI 服务器听起来很完美）

定期运行“有趣”的测试比很少运行所有的测试要好。

score 0 · Accepted Answer

我会通过在提交之前运行必须运行1 分钟或更短时间的测试子集（“冒烟测试”）来解决这个问题，然后从 CI 服务器运行全套测试。

如果您的全套测试需要超过 15 分钟，那么我会考虑将它们分开并并行运行。

然后你可以使用 --filter 首先运行你最感兴趣的测试，然后是提交之前的冒烟测试，其余的从 CI 服务器运行。

3 回答 3