c – 使用GoogleTest测试私有方法的最佳方法是什么？

我想使用GoogleTest测试一些私有方法.

class Foo
{
private:
    int bar(...)
}

GoogleTest允许使用两种方法.

选项1

使用FRIEND_TEST：

class Foo
{
private:
    FRIEND_TEST(Foo, barReturnsZero);
    int bar(...);
}

TEST(Foo, barReturnsZero)
{
    Foo foo;
    EXPECT_EQ(foo.bar(...), 0);
}

这意味着在生产源文件中包含“gtest / gtest.h”.

方案2

将测试夹具声明为类的朋友并在夹具中定义访问器：

class Foo
{
    friend class FooTest;
private:
    int bar(...);
}

class FooTest : public ::testing::Test
{
protected:
    int bar(...) { foo.bar(...); }
private:
    Foo foo;
}

TEST_F(FooTest, barReturnsZero)
{
    EXPECT_EQ(bar(...), 0);
}

方案3

Pimpl成语.

详情：Google Test: Advanced guide.

有没有其他方法来测试私有方法？每种选择有哪些优缺点？

解决方法:

还有至少两个选项.我将通过解释某种情况列出你应该考虑的其他一些选项.

选项4：

考虑重构代码,以便您要测试的部分在另一个类中是公共的.通常,当你想要测试一个类的私有方法时,它就是设计糟糕的标志.我看到的最常见的(反)模式之一是Michael Feathers所谓的“冰山”课程. “Iceberg”类有一个公共方法,其余的都是私有的(这就是测试私有方法的原因).它可能看起来像这样：

例如,您可能希望通过在字符串上连续调用它并看到它返回预期结果来测试GetNextToken().像这样的函数确实需要进行测试：这种行为并不简单,特别是如果您的标记化规则很复杂.让我们假装它并不是那么复杂,我们只想把空间划分为令牌.所以你写了一个测试,也许它看起来像这样：

TEST(RuleEvaluator, canParseSpaceDelimtedTokens)
{
    std::string input_string = "1 2 test bar";
    RuleEvaluator re = RuleEvaluator(input_string);
    EXPECT_EQ(re.GetNextToken(), "1");
    EXPECT_EQ(re.GetNextToken(), "2");
    EXPECT_EQ(re.GetNextToken(), "test");
    EXPECT_EQ(re.GetNextToken(), "bar");
    EXPECT_EQ(re.HasMoreTokens(), false);
}

嗯,这实际上看起来很不错.我们希望确保在进行更改时保持这种行为.但GetNextToken()是一个私有函数！所以我们不能这样测试它,因为它甚至不会编译.但是如何更改RuleEvaluator类以遵循单一责任原则(单一责任原则)？例如,我们似乎有一个解析器,标记器和评估器卡在一个类中.将这些责任分开是不是更好？最重要的是,如果你创建一个Tokenizer类,那么它的公共方法将是HasMoreTokens()和GetNextTokens(). RuleEvaluator类可以将Tokenizer对象作为成员.现在,我们可以保持与上面相同的测试,除了我们测试Tokenizer类而不是RuleEvaluator类.

这是UML中的样子：

请注意,这种新设计增加了模块化,因此您可能会在系统的其他部分中重复使用这些类(在您不能之前,私有方法根​​据定义不可重用).这是打破RuleEvaluator的主要优势,同时增加了可理解性/局部性.

测试看起来非常相似,除非它实际上会编译,因为GetNextToken()方法现在在Tokenizer类上是公共的：

TEST(Tokenizer, canParseSpaceDelimtedTokens)
{
    std::string input_string = "1 2 test bar";
    Tokenizer tokenizer = Tokenizer(input_string);
    EXPECT_EQ(tokenizer.GetNextToken(), "1");
    EXPECT_EQ(tokenizer.GetNextToken(), "2");
    EXPECT_EQ(tokenizer.GetNextToken(), "test");
    EXPECT_EQ(tokenizer.GetNextToken(), "bar");
    EXPECT_EQ(tokenizer.HasMoreTokens(), false);
}

选项5

只是不要测试私有功能.有时他们不值得测试,因为他们将通过公共界面进行测试.很多时候,我看到的测试看起来非常相似,但测试两种不同的功能/方法.最终发生的事情是,当需求发生变化时(他们总是这样做),你现在有2个破坏的测试而不是1.如果你真的测试了所有的私有方法,你可能会有更多像10个破坏的测试而不是1个.简而言之. ,测试私有函数(通过使用FRIEND_TEST或公开它们)否则可以通过公共接口测试导致测试重复.你真的不想要这个,因为没有什么比你的测试套件更让你失望的伤害.它应该减少开发时间并降低维护成本！如果您测试通过公共接口进行测试的私有方法,那么测试套件可能会做相反的事情,并积极地增加维护成本并增加开发时间.当你公开私人功能,或者你使用像FRIEND_TEST这样的东西时,你通常会后悔.

考虑以下Tokenizer类的可能实现：

假设SplitUpByDelimiter()负责返回std :: vector< std :: string>这样向量中​​的每个元素都是一个标记.此外,我们只是说GetNextToken()只是这个向量的迭代器.所以你的测试看起来像这样：

TEST(Tokenizer, canParseSpaceDelimtedTokens)
{
    std::string input_string = "1 2 test bar";
    Tokenizer tokenizer = Tokenizer(input_string);
    EXPECT_EQ(tokenizer.GetNextToken(), "1");
    EXPECT_EQ(tokenizer.GetNextToken(), "2");
    EXPECT_EQ(tokenizer.GetNextToken(), "test");
    EXPECT_EQ(tokenizer.GetNextToken(), "bar");
    EXPECT_EQ(tokenizer.HasMoreTokens(), false);
}

// Pretend we have some class for a FRIEND_TEST
TEST_F(TokenizerTest, canGenerateSpaceDelimtedTokens)
{
    std::string input_string = "1 2 test bar";
    Tokenizer tokenizer = Tokenizer(input_string);
    std::vector<std::string> result = tokenizer.SplitUpByDelimiter(" ");
    EXPECT_EQ(result.size(), 4);
    EXPECT_EQ(result[0], "1");
    EXPECT_EQ(result[1], "2");
    EXPECT_EQ(result[2], "test");
    EXPECT_EQ(result[3], "bar");
}

好吧,现在让我们说需求会发生变化,现在你需要用“,”而不是空格来解析.当然,你会期望一个测试中断,但是当你测试私有函数时疼痛会增加. IMO,谷歌测试不应该允许FRIEND_TEST.这几乎不是你想要做的. Michael Feathers将像FRIEND_TEST这样的东西称为“摸索工具”,因为它试图触摸别人的私人部分.

我建议尽可能避免使用选项1和2,因为它通常会导致“测试重复”,因此,当需求发生变化时,会有许多不必要的测试会中断.使用它们作为最后的手段.选项1和2是在这里和现在“测试私有方法”的最快方法(如同最快实施),但从长远来看,它们确实会损害生产力.

PIMPL也有意义,但它仍然允许一些非常糟糕的设计.小心一点.

我建议将Option 4(重构为较小的可测试组件)作为正确的起点,但有时你真正想要的是Option 5(通过公共接口测试私有函数).

附：这是关于冰山课程的相关讲座：https://www.youtube.com/watch?v=4cVZvoFGJTU

P.S.S.至于软件中的一切,答案取决于它.没有一种尺寸适合所有人.解决问题的选项取决于您的具体情况.

标签：c,unit-testing,private,googletest
来源： https://codeday.me/bug/20191003/1850948.html