单元测试 C++ SetUp() 和 TearDown()答案

【问题标题】：Unit testing C++ SetUp() and TearDown()单元测试 C++ SetUp() 和 TearDown()
【发布时间】：2014-09-25 04:45:17
【问题描述】：

我目前正在使用google mock 学习单元测试virtual void SetUp() 和virtual void TearDown() 在google mock 中的通常用途是什么？带有代码的示例场景会很好。

【问题讨论】：

mock 没有这样的方法。这些是 test fixture 上的方法，它是 Google Test 的一个组件，而不是 Google Mock。通常，您可能确实需要这些方法，因为构造函数和析构函数将用于相同的目的。见the documentation 和the FAQ。
google mock中没有这个功能，是google test的

标签： unit-testing googlemock

【解决方案1】：

它可以在每个测试的开始和结束时分解您想要执行的代码，以避免重复。

例如：

namespace {
  class FooTest : public ::testing::Test {

  protected:
    Foo * pFoo_;

    FooTest() {
    }

    virtual ~FooTest() {
    }

    virtual void SetUp() {
      pFoo_ = new Foo();
    }

    virtual void TearDown() {
      delete pFoo_;
    }

  };

  TEST_F(FooTest, CanDoBar) {
      // You can assume that the code in SetUp has been executed
      //         pFoo_->bar(...)
      // The code in TearDown will be run after the end of this test
  }

  TEST_F(FooTest, CanDoBaz) {
     // The code from SetUp will have been executed *again*
     // pFoo_->baz(...)
      // The code in TearDown will be run *again* after the end of this test

  }

} // Namespace

【讨论】：

链接因区分大小写而中断（Primer.md 与primer.md）。这是当前的：github.com/google/googletest/blob/master/googletest/docs/…
如果我的测试在与模拟类不同的文件上怎么办？有没有什么方法可以在没有命名空间的情况下激活 SetUp 和 TearDown？
由于目录结构，链接再次断开。这是最新的：github.com/google/googletest/blob/master/docs/…

【解决方案2】：

测试代码倾向于充满代码重复：编写单独的测试方法来测试被测代码的不同方面是一种很好的做法。其结果是，对于某些测试功能，可能有相当多的不同测试方法。而且，所有这些方法都必须（原则上）实现以下步骤：

准备（设置）被测代码的执行。这样做的目的是确保在执行时，被测代码的环境和输入完全在测试的控制之下。
执行（练习）被测代码。
评估（验证）结果，即检查实际结果是否符合预期。
如有必要，清理（拆除），以便后续测试可以从定义的起点开始。通常在此步骤中分配的资源被释放，创建的文件被删除等。

由于这些活动对所有测试方法都是通用的，并且每个测试功能都有多个测试方法，因此可能存在一定数量的代码重复，尤其是在不同的设置和拆卸阶段。为了克服这个问题，测试框架提供了将通用设置和拆卸代码放入特殊方法的可能性，以防 Google Test SetUp 和 TearDown。

然后执行模型如下：首先，创建具有测试方法的类的新实例（又名 gtest 中的固定装置），这意味着调用了构造函数。其次，在该实例上运行 SetUp 方法（如果有）。这使 SetUp 方法有机会执行不同测试方法之间常见的所有设置活动。第三，调用相应的测试方法（只是其中之一！）。再次，设置/练习/验证/拆卸发生，但关于设置，只有那些尚未被 SetUp 方法覆盖的活动必须完成。同样，只有针对该测试方法的那些拆解活动才在测试方法中完成。第四，调用 TearDown 方法进行常见的清理活动，最后销毁实例（调用析构函数）。然后，针对下一个测试方法执行这五个步骤，以此类推。

TearDown 的 SetUp 的总体思路就到此为止。但是，在实施测试时要记住一些事情：当然，SetUp 和 TearDown 可以帮助减少跨测试的代码重复。但是，它们的使用可能会导致不同类型的问题：

测试方法的代码可能会变得晦涩难懂，因为与了解测试如何工作相关的一些活动位于 SetUp 方法中。当然，有经验的开发人员会知道，在尝试理解测试方法时，他们还应该研究 SetUp 和 TearDown，但测试代码的可读性会受到负面影响。
SetUp 方法倾向于跨测试方法累积功能：如果您有三个测试方法，其中两个共享一些设置代码，则可以将其添加到 SetUp 方法中。对于稍后阅读测试代码的读者来说，理解 SetUp 的哪些部分实际上属于哪个测试方法变得更加困难。这也使得对 SetUp 进行修改变得更加困难，因为预测哪些测试方法会受到更改的影响变得更加困难。

因此，采用不同的方法来减少跨测试方法的代码重复可能是有益的。您可以执行以下操作，而不是将通用代码放入由测试框架隐式调用的 SetUp 和 TearDown和拆解代码。当然，这些方法不会在每个测试方法之前被隐式调用，而是您会显式调用它们。这会留下一些代码重复，但带来的好处是，从测试方法本身可以清楚地看出实际发生了哪些设置活动。您自己的辅助方法当然可以接受参数，例如“ensureTrafficLightIs(Green)”。

【讨论】：