发送到应用程序的 CTRL-C 的单元测试答案

【问题标题】：unit testing for CTRL-C sent to an application发送到应用程序的 CTRL-C 的单元测试
【发布时间】：2011-05-28 21:34:17
【问题描述】：

我正在开发一个处理 CTRL-C 的应用程序。我正在生成一个信号处理程序来优雅地关闭线程和其他资源。

我想在我的应用程序可能存在的不同场景中测试 CTRL-C。我知道如何为被测进程设置这些，但我需要一种方法（在正在运行的测试套件的代码中）检查是否达到该条件以准确调用 CTRL-C.

我在 Linux 中工作，我想在 CPPUNIT 的帮助下自动运行我的测试。在我的每个 CTRL-C 测试中，我都会启动该过程，然后使用 @987654323 发送 CTRL-C @函数有进程的PID。

我正在使用共享内存；一旦测试的应用程序达到我感兴趣的条件或我想发送 CTRL-C 的点，我将标签或状态写入共享内存。同时，在不同进程中运行的测试套件代码不断地轮询共享内存，一旦读取到所需的状态，它就会发送 CTRL-C/kill。

您认为这是一种好方法还是通常以更好/有效的方式完成？

亲切的问候

AFG

【问题讨论】：

【解决方案1】：

在接收到一些外部信号时首先测试行为看起来不像单元测试，而是像功能测试。

此外，您执行此操作的方式也听起来过于复杂，并且可能会强制进行某种同步并隐藏某些行为。

另一方面，对于这种测试，我真的没有什么更好的建议，这通常是由外部工具以一种不受控制的方式完成的。

【讨论】：

我明白你的意思。某种“太复杂”的代码也反对。你是指什么样的工具？这些是免费/开源的吗？
+1 测试信号处理程序对我来说听起来也像是功能测试。
+1，它确实是用于功能测试 - 不是用于单元测试
我不明白。为什么这种类型的测试不应该在单元测试套件中？我想确保正确释放资源，正确写入存储要在以下时间重用的数据的文件（测试我期望写入的内容），甚至可以正确重新启动应用程序..etc...对我来说功能是为了确保当我按下按钮在 GUI 上执行某些操作时，它实际上会执行。我个人也会测试我在测试套件中描述的内容。不是吗？如果不能，你能快速告诉我为什么吗？
@abruzzo-forte-e-gentile：单元测试是关于使用您的编程语言内部 API 调用某些函数。那不是您的测试正在做的事情。功能测试确实是关于用户（即：外部世界）与您的程序的交互。获取信号是外部世界的交互，您甚至可以将其称为一种残酷的 GUI，例如在没有足够内存或磁盘空间的系统上运行程序等情况。作为功能测试并不意味着它不重要或不想将其放入测试套件中。

【解决方案2】：

引入一个间接级别。

将您的高级程序代码放在 Facade 后面（我使用名为 Program 的类）。
让 Facade 提供一个 shutdown() 方法，该方法执行除了调用 std::exit() 之外的所有关闭操作。
对shutdown() 方法进行单元测试，就像对任何其他方法一样。
将信号处理程序委托给 shutdown() 方法，用于代表整个程序的 static Program 对象，然后是 call std::exit()。这是唯一不能进行单元测试的部分。

【讨论】：

您好，谢谢。我已经做了一些非常相似的事情。我的 main() 函数基本上为您创建了一个“程序”类的实例。如果我在单元测试中使用它并为“程序”设置一个信号处理程序；类，然后我将为测试运行程序设置一个信号处理程序，我想避免这种情况并尝试将其作为真实情况，即我可以从外部调用的单独进程杀死。无论如何，我会尝试更好地挖掘静态关闭（）的想法。为此，我必须审查信号处理。它们的要求非常严格。
如果我遵循您的方法，我必须确保在测试套件的 setUp()/tearDown() 期间恢复原始信号处理程序。我认为这可能值得一试。
您可以将您的测试要求一分为二：收到 SIGTERM 是否会导致受控关闭，以及受控关闭是否正确释放资源、关闭文件等。单元测试可以帮助您解决第二个问题，通过测试你的 shutdown() 方法，但它不适合第一个。
只是一个便条，有很大的延迟（我正在经历上一期的所有回复）来告诉你进展如何。您的建议很好，但由于不切实际的原因，我留下了 CPPUNIT 以达到更接近功能测试的目的（如 kriss 所建议）。我在 PERL 中嵌入了所有内容（包括您关闭应用程序 + 从外部调用 SIGINT 的方式）。