c++ - 单元测试处理退化的网络堆栈、文件损坏和其他缺陷

Question

我主要是一个 C++ 编码员，到目前为止，我没有真正为我的所有代码编写测试。我已经决定这是一个坏主意(tm)，在添加了巧妙地破坏旧功能的新功能之后，或者，根据您希望如何看待它，引入了一些自己的新“功能”。

但是，单元测试似乎是一种极其脆弱的机制。您可以在“完美”条件下测试某些内容，但您无法看到代码在出现问题时的执行情况。例如，一个爬虫是一个爬虫，假设它爬取一些特定的站点，数据 X。你是否只是保存示例页面，针对这些页面进行测试，并希望这些站点永远不会改变？这作为回归测试可以正常工作，但是，您会编写什么样的测试来不断检查这些站点的实时状态，并让您知道应用程序何时无法正常工作，因为站点更改了某些内容，现在导致您的应用程序崩溃？您不想让您的测试套件监控代码的意图吗？

上面的例子有点做作，我还没有遇到过(以防你没有猜到)。不过，让我挑选一些我拥有的东西。面对降级的网络堆栈，您如何测试应用程序是否能正常工作？也就是说，假设您有适度的数据包丢失，出于某种原因或其他原因，并且您有一个函数 DoSomethingOverTheNetwork()当堆栈没有按预期执行时，它应该优雅地降级；但是呢？开发人员通过故意设置一个网关来亲自测试它，该网关在他第一次编写时会丢弃数据包以模拟不良网络。几个月后，有人检查了一些代码，修改了一些微妙的东西，所以没有及时检测到降级，或者，应用程序甚至没有识别降级，这永远不会被发现，因为你不能在现实世界中运行像这样的测试使用单元测试，你能吗？

此外，文件损坏如何？假设您将服务器列表存储在一个文件中，并且校验和看起来没问题，但数据并非如此。你想要代码来处理它，你编写了一些你认为可以做到的代码。您如何测试它在应用程序的整个生命周期内是否确实如此？你是否可以？

因此，脆性。单元测试似乎只在完美的条件下测试代码(这是促进的，使用模拟对象等)，而不是他们将在野外面临的情况。不要误会我的意思，我认为单元测试很棒，但是仅由它们组成的测试套件似乎是一种聪明的方法，可以在代码中引入细微错误，同时对其可靠性感到过度自信。

我如何解决上述情况？如果单元测试不是答案，那是什么？

编辑:我看到很多答案都说“只是 mock 它”。好吧，你不能“只是 mock 它”，原因如下:
以我的降级网络堆栈为例，让我们假设您的函数有一个定义明确的 NetworkInterface，我们将对其进行模拟。应用程序通过 TCP 和 UDP 发送数据包。现在，让我们说，嘿，让我们使用模拟对象在界面上模拟 10% 的损失，看看会发生什么。您的 TCP 连接会增加它们的重试尝试，以及增加它们的回退，所有这些都是很好的做法。您决定更改 X% 的 UDP 数据包以实际建立 TCP 连接，有损接口(interface)，我们希望能够保证某些数据包的交付，而其他数据包不应丢失太多。效果很好。同时，在现实世界中……当您增加 TCP 连接(或 TCP 上的数据)的数量时，在一个足够有损的连接上，您最终会增加 UDP 数据包丢失，因为您的 TCP 连接最终会重新- 越来越多地发送他们的数据和/或减少他们的窗口，导致你 10% 的数据包丢失实际上更像是 90% 的 UDP 数据包丢失。哎呀。

没什么大不了的，让我们把它分解成 UDPInterface 和 TCPInterface。等一下.. 那些是相互依赖的，测试 10% UDP 丢失和 10% TCP 丢失与上述没有什么不同。

所以，现在的问题是，您不是简单地对代码进行单元测试，而是将您的假设引入操作系统的 TCP 堆栈的工作方式中。而且，这是一个坏主意(tm)。一个比避免整个惨败更糟糕的主意。

在某些时候，您将不得不创建一个模拟操作系统，它的行为与您的真实操作系统完全一样，只是可测试。这似乎不是一个好的前进方向。

这是我们经历过的事情，我相信其他人也可以添加他们的经历。

我希望有人会告诉我我错了，并指出原因!

谢谢!

Answer 1

阅读任何关于单元测试的体面书籍 - 您会发现编写测试确实涵盖了输入不理想或完全错误的边缘情况是正常的做法。

具有异常处理的语言中最常见的方法是“应该抛出”规范，其中预期某个测试会导致抛出特定的异常类型。如果它不抛出异常，则测试失败。

更新

在您的更新中，您描述了复杂的时间敏感交互。单元测试根本没有帮助。无需引入网络:只需考虑尝试编写一个简单的线程安全队列类，也许在具有一些新并发原语的平台上。在 8 核系统上测试它......它有效吗？您根本无法通过测试来确定这一点。有太多不同的方式会导致时序在内核之间重叠操作。取决于运气，可能需要数周的连续执行才能发生一些不太可能的巧合。使这些事情正确的唯一方法是通过仔 segmentation 析(静态检查工具可以提供帮助)。大多数并发软件可能都有一些很少发生的错误，包括所有操作系统。

回到实际可以测试的案例，发现集成测试 通常和单元测试一样有用。这可以像自动安装产品一样复杂，向其中添加配置(例如您的用户可能创建)，然后从外部“戳”它，例如自动化您的用户界面。这发现了与单元测试分开的另一类问题。