单元测试c ++ setup()和拆解()

Question

目前,我正在学习单元测试谷歌假装什么是平时使用virtual void SetUp(),并virtual void TearDown()在谷歌模仿？使用代码的示例场景将是好的.提前致谢.

Answer 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

Answer 2

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

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

由于这些活动对所有测试方法都是通用的，并且由于每个测试功能有多种测试方法，因此可能存在一定数量的代码重复，特别是在不同的设置和拆除阶段。为了克服这个问题，测试框架提供了将常见的设置和拆卸代码放入特殊方法中的可能性，在谷歌测试设置和拆卸的情况下。

执行模型如下：首先，创建带有测试方法（在 gtest 中也称为夹具）的类的新实例，这意味着调用构造函数。其次，在该实例上运行 SetUp 方法（如果有）。这使设置方法有机会执行不同测试方法之间通用的所有设置活动。第三，调用相应的测试方法（只是其中之一！）。在这里，再次发生设置/练习/验证/拆卸，但关于设置，只有那些尚未被 SetUp 方法覆盖的活动必须完成。同样，只有那些特定于该测试方法的拆卸活动在测试方法内完成。第四，调用 TearDown 方法执行常见的清理活动，最后销毁实例（调用析构函数）。

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

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

因此，采用不同的方法来减少跨测试方法的代码重复可能是有益的。您可以执行以下操作，而不是将公共代码放入测试框架隐式调用的 SetUp 和 TearDown 中：您创建自己的辅助方法，这些方法具有易于理解的名称，例如“ensureTrafficLightIsGreen”，其中包含相应的公共设置和拆卸代码。这些方法当然不会在每个测试方法之前隐式调用，而是您会显式调用它们。这留下了一些代码重复，但带来的好处是，从测试方法本身可以清楚地知道哪些设置活动实际发生。您自己的辅助方法当然可以带参数，例如“ensureTrafficLightIs(Green)”。