C++ Google Test测试夹具的构造器定义

我最近使用Google Test for C++代码。当我阅读如何设置测试夹具时，我感到有点困惑。 Writing the main() Function会议展示了一个关于测试夹具类看起来像什么的例子。但是，当涉及到构造函数定义时，我们应该把它放在测试夹具类中吗？例如，就像谷歌测试文档给出下面的代码片段：C++ Google Test测试夹具的构造器定义

class FooTest : public ::testing::Test { 
protected: 
    // You can remove any or all of the following functions if its body 
    // is empty. 

    FooTest() { 
    // You can do set-up work for each test here. 
    } 

    virtual ~FooTest() { 
    // You can do clean-up work that doesn't throw exceptions here. 
    } 
}

我也看了在宏观TEST_F(test_fixture_name, test_name)的定义，它似乎是与同一测试夹具相关联的每个测试，宏将创建一个测试夹具类的新子类。

鉴于上述事实，

如果构造的工作是沉重的，这是否意味着测试夹具的构造将让编译器扩展构造的大块的代码随处可见的隐含inline？（或者在同一个翻译单元中这没有关系？）
在这种情况下，在测试夹具类之外定义构造函数是否更有意义？但是这样会使测试代码不易读，我不知道该怎么办。

有没有人可以给我一些建议呢？谢谢！

来源

2017-01-10 Dreamer

关于问题1，完全取决于编译器 - 它具有广泛的自由度来决定是否以及如何内联函数。即使您明确声明函数为inline，但就编译器而言，它仍然只是一个建议，如果它决定生成的机器代码太臃肿或效率低下，则可以自由忽略该建议。

的C++ FAQ对话题的更多细节：

有几种方法来指定一个功能是内联，其中一些涉及inline关键字，有的则没有。无论您如何将函数指定为内联函数，它都是允许编译器忽略的请求：编译器可能会内联展开一些或全部或者没有调用指定为内联的函数的地方。（如果看起来毫无希望地模糊，不要灰心，上面的灵活性实际上是一个巨大的优势：它可以让编译器把大的函数与小函数区分开来，再加上它让编译器生成代码，如果你选择了易于调试的代码正确的编译器选项。）

在问题2中，我建议您只需要找出最具可读性的内容。当我使用Google测试时，我亲自将所有“共享”代码放入测试夹具定义中，然后立即对该夹具中运行的所有单元测试执行TEST_F声明。

class MyTestCase : public ::testing::Test 
{ 
    virtual void SetUp() override 
    { 
     // ... 
    } 
} 

TEST_F(MyTestCase, UnitTestNumber1) 
{ 
    // testing stuff here 
} 

// ...more tests...

虽然这只是一个建议。选择适合您的标准并持续使用。

来源

2017-01-10 01:36:32

C++ Google Test测试夹具的构造器定义

回答

相关问题