TDD 测试周期区分测试类型的技术？

Question

这门艺术的新手...但到目前为止，根据我的阅读，我了解大致有 3 类：单元测试、验收/集成测试（不一样）和端到端测试。

问题是，在这 3 个中，似乎只有单元测试才能以闪电般的速度运行。在开发过程中一直运行整个项目的所有单元测试似乎是完全合理的。但是，其他类型似乎不能这么说。

因此，在我看来，您希望在每次测试运行时运行一个验收测试（或者可能是一组相关的测试），同时为整个项目运行所有单元测试。

至于处于“红色”状态的最新端到端测试，考虑到这些测试甚至比验收测试还要慢，您难道不想间歇性地运行它吗？而整个端到端的收集可能只有在您做其他事情时，或者在晚上或其他情况下？

我正在使用 Gradle，并且我知道您可以创建一个特殊的测试任务来仅运行，例如，tests\unittests 目录下的所有单元测试......但是，如果我的想法是有效的，那就是除了不断编辑代码之外，还有一种习惯性的方法可以跳过或选择特定的验收测试——这会变得很烦人吗？

例如，通过某种方式将特定的验收或端到端测试标记为某个“类别”，或者将这些测试安排在分层文件夹结构中？

Answer 1

我没有使用过gradle，但是在python中我经常使用你描述的两种方式：

• 标记特定类别的功能测试（一个子集通常标记为“冒烟”测试，在每次部署时运行）
• 在层次结构中表示测试
  • 小/单位
  • 集成
  • 功能（烟雾通常被标记为功能测试）
  • ui
  • e2e

---

似乎只有单元测试才能以闪电般的速度运行。为整个项目运行所有单元测试似乎是完全合理的，

这是我们的目标，我们鼓励所有的单元测试都是无 IO 的，在每次提交时都可以快速运行。此过程通常与 CI 构建作业一起编码，以在每次提交到 repo 时触发。

但其他类型似乎不能这么说。 这实际上取决于可接受的构建时间以及项目的大小。我发现大多数项目实际上并没有那么多集成，如果它们确实有过多的集成，这通常是一个很好的迹象，表明应该重新考虑服务。对于永远的集成，需要多少测试来防止难以重现的错误情况，并确保它们是会在接口更改时中断的检查？以我的经验，并不多。我最近开始使用docker-compose 进行集成测试，这使得每次提交都可以非常快速地执行许多测试 20-30。

docker-compose 还允许建立一个干净的 e2e 环境，以便对其执行验收/功能测试。

根据我的经验，更高级别的测试执行频率较低，但应尽可能频繁地执行。例如，我使用一个 API，包含 300 个功能测试，涵盖每个端点上的每个方法。因为它们不与 UI 交互并且只使用 HTTP，所以它们需要大约一分钟的时间来执行。它们在每次部署到环境时定期执行。