隔离单元测试

一般而言，良好的面向对象实践足以保持单元测试的独立性。然而，当程序崩溃，破坏内存空间等事情变得非常糟糕时，事情可能会蔓延到相邻的测试中，并给出令人误解的结果，或者只是简单地引起讨厌的测试框架。有没有人知道任何现有的单元测试框架都有很高的隔离级别来防止这种事情发生？举个例子，一个简单的方法就是在命令行上一次执行一个设备，但我担心很难很好地汇总结果。我现在想要的这个C++项目在cppunit中，但是如果像Google Test Framework或CTest这样的支持有这种支持，我还没有死在那个框架上。我简单地看看那两个，我不认为我看到任何有这种严格隔离的东西。我主要对Linux感兴趣，但跨平台将是理想的。隔离单元测试

在任何情况下，如果有人感兴趣，我可以使用cppunit使用小型Linux（可能是其他人）的概念证明。查找文件在 https://github.com/JohnDMcMaster/uvudec/tree/master/uvudec/testing/framework 你会想helper_macros。*，serialized_test_result。*和test_caller。*

来源

2012-01-01 McFluffin

为什么难以汇总结果？ – 2012-01-01 04:42:23

我不确定我是否遵循这一点。如果单元测试崩溃你的测试程序，后续的测试将不会运行。当您修复测试（或测试中的系统）时，随后的测试运行。你能举一个你想要防止的泄漏的例子吗？ – Johnsyweb 2012-01-01 04:46:29

有这样的没有框架。您需要为每个测试制作独立的测试套件，以便它们是独立的文件。这将允许它们完全隔离地运行。

取而代之，您可以使用boost.test，因为它可以检测Windows上的内存泄漏，这是我认为的正确方向的一步。

来源

2012-03-07 13:23:37

您应该添加Boost.Test只能检测Windows下的内存泄漏。 – 2012-03-07 13:30:14

@honk - 不知道。谢谢！ – 2012-03-07 13:35:02

对于这种事情自然隔离单元的过程中，我会说这也是此类问题的自然粒度级别：

如果所有的单元测试被编译成一个可执行，很有可能它们速度太快，以至于你不在乎是否崩溃会迫使你重复（一组）套件。另一方面，如果你所有的单元测试都是如此之多并且需要很长时间才能运行，那么一个中断测试运行的崩溃是一个主要的烦恼，那么你应该将它们分成几个exes以使你的单元测试更多ganular。（链接时间，开发人员很容易只能运行一个子集，...）

来源

2012-08-22 07:48:27

隔离单元测试

回答

相关问题