一般来说，良好的OO实践足以使单元测试分开。然而，当事情因程序崩溃，破坏内存空间等而变得非常糟糕时，事情可能会蔓延到相邻的测试并产生误导性的结果，或者只是令人讨厌，因为它会导致测试框架崩溃。有没有人知道任何现有的单元测试框架具有高水平的隔离，以防止这种事情？举个例子，一个简单的方法是在命令行上一次执行一个fixture，但我担心很难很好地聚合结果。我目前想要的C ++项目是cppunit，但是如果谷歌测试框架或CTest这样的东西有这种支持，我就不会死在那个框架上。我简要地看一下这两个，我认为我没有看到任何严格孤立的东西。我最感兴趣的是Linux，但跨平台是理想的。
无论如何，如果有人感兴趣的话，我会使用cppunit玩一个小的Linux（可能还有其他）概念证明。找到文件 https://github.com/JohnDMcMaster/uvudec/tree/master/uvudec/testing/framework 你需要helper_macros。*，serialized_test_result。*和test_caller。*
答案 0 :(得分：0)
没有像这样的框架。您需要为每个测试制作单独的测试套件，以便它们是单独的文件。这将允许它们完全隔离运行。
而不是这个，你可以使用boost.test，因为它检测到Windows上的内存泄漏，这在我看来是朝着正确方向迈出的一步。
答案 1 :(得分：0)
这类事物的自然隔离单元就是这个过程，我想它也是这类问题的自然粒度级别：
如果所有的单元测试都被编译成一个可执行文件，那么很可能它们是如此之快以至于您不关心崩溃的单元测试是否会强制您重复（套件）套件。
另一方面，如果你所有的单元测试都是这么多并且需要很长时间才能运行，那么一个中断测试运行的崩溃是一个主要的烦恼，那么你应该将它们分成几个exes，无论如何要使你的单元测试更多ganular。 （链接时间，开发人员很容易只能运行子集，...）