如何处理长时间运行的单元测试？

题

我有大约 100 个单元测试，覆盖率为 %20，我正在尝试增加覆盖率，而且这是一个正在开发的项目，因此请不断添加新的测试。

目前在每次构建后运行我的测试是不可行的，它们大约需要 2 分钟。

测试包括：

大多数功能需要读取 HTTP、执行 TCP 等。我无法更改它们，因为这就是项目的整个想法，如果我更改这些测试，那么测试东西将毫无意义。

另外，我认为我没有运行单元测试最快的工具。我当前的设置使用 VS TS，以 Gallio 和 nUnit 作为框架。我认为VS TS + Gallio也比其他人慢一点。

您会建议我做什么来解决这个问题？我想在每一点点改变 btu 之后运行单元测试，目前这个问题正在中断我的流程。

进一步澄清编辑：

代码是 耦合度高！ 不幸的是，改变就像一个巨大的重构过程。这里面有一个鸡先有蛋综合症，我需要单元测试来重构这么大的代码，但如果我不重构它，我就无法进行更多的单元测试:)

高度耦合的代码不允许我将测试分成更小的块。另外，我不测试私人的东西，这是个人选择，这让我发展得更快，并且仍然获得大量的好处。

我可以确认所有单元测试（具有适当的隔离）实际上都非常快，并且我对它们没有性能问题。

进一步澄清：

高度耦合的代码不允许我将测试分成更小的块。另外，我不测试私人的东西，这是个人选择，这让我发展得更快，并且仍然获得大量的好处。

我可以确认所有单元测试（具有适当的隔离）实际上都非常快，并且我对它们没有性能问题。

解决方案

对我来说，这些听起来不像单元测试，而更像功能测试。没关系，自动化功能测试很好，但功能测试速度很慢是很常见的。他们正在测试整个系统（或其中的大部分）。

单元测试往往很快，因为它们测试的是与其他所有事物隔离的一件事。如果您无法独立于其他所有内容进行测试，那么您应该考虑到您编写的代码的警告标志太过分了。 紧密耦合.

你能告诉你哪些测试是单元测试（仅测试 1 件事）还是单元测试？功能测试（同时测试 2 个或更多事物）？哪些快，哪些慢？

其他提示

您可以将测试分为两组，一组用于短期测试，一组用于长时间运行的测试，并降低运行长时间测试的频率，同时在每次更改后运行短期测试。除此之外，模拟来自网络服务器的响应和应用程序发出的其他请求将导致测试运行时间缩短。

我会推荐一种综合方法来解决您的问题：

经常运行与您更改的代码接近的测试子集（例如来自同一包、模块或类似内容的测试）。不太频繁地运行距离您当前正在处理的代码较远的测试。
将您的套房至少分成两部分：快速运行和慢速运行的测试。更频繁地运行快速运行的测试。
考虑让一些不太可能失败的测试仅由自动持续集成服务器执行。
学习提高测试性能的技术。最重要的是，通过更快的伪造取代对缓慢系统资源的访问。例如，在内存流中使用而不是在文件中使用。存根/模拟 http 访问。ETC。
了解如何使用低风险依赖破坏技术，例如（强烈推荐）“有效处理遗留代码”一书中列出的技术。这些使您能够有效地使代码更具可测试性，而无需应用高风险重构（通常会暂时使实际设计变得更糟，例如破坏封装，直到您可以使用测试安全网重构为更好的设计）。

我从上面提到的书中学到的最重要的事情之一：使用遗留代码并没有什么神奇之处是痛苦，并且总是将疼痛。你能做的就是接受这个事实，并尽力慢慢摆脱困境。

首先，这些不是单元测试。

在每次小的改变之后运行这样的功能测试并没有多大意义。经过相当大的更改后，您将需要运行功能测试。

其次，不要害怕模拟应用程序的 Http 部分。如果您确实想对应用程序进行单元测试，那么它是必须的。如果您不愿意这样做，您将浪费更多时间尝试测试实际逻辑、等待 HTTP 请求返回并尝试设置数据。

我会保留您的集成级别测试，但努力创建真正的单元测试。这将解决您的速度问题。真正的单元测试没有数据库交互，也没有HTTP交互。

我总是使用“LongTest”类别。这些测试每晚执行，而不是白天执行。这样您就可以大大减少等待时间。尝试一下：对您的单元测试进行分类。

听起来您可能还需要管理开发团队的期望。

我假设人们每天都会进行多次构建，并且预计在每次构建后运行测试。您可能会很乐意将您的测试计划更改为在午餐期间运行测试构建，然后在晚上运行另一个测试。

我同意布拉德的观点，这些听起来像是功能测试。如果您可以将代码分开，那就太好了，但在那之前我会切换到不太频繁的测试。

许可以下： CC-BY-SA 和归因