测试覆盖度和可重用性问题

Question

我不太擅长编写单元测试，所以我陷入了两难境地。我有一个binary_search_tree，我正在为insert和contains方法编写测试：

struct BinarySearchTree {};

TEST(BinarySearchTree, Insert) {
    BinarySearchTree t;
    t.insert(5);
    EXPECT_TRUE(t.contains(5));
}

TEST(BinarySearchTree, Contains) {
    BinarySearchTree t;
    t.insert(5);
    EXPECT_FALSE(t.contains(2);
    EXPECT_TRUE(t.contains(5);
}

如您所见，它们是相互关联的，这些测试用例可能完全相等，因为：

1. 我们通过插入元素来测试插入，并检查树是否包含它。
2. 我们通过插入元素和检查是否包含元素来测试元素的存在性。

所以我有两个选择：

1. 不要为contains编写测试，因为它将在{插入、删除、替换等}测试中进行测试。
2. 在所有这些测试中编写几乎相同的内容。

还有什么更好的？

Answer 1

单元测试测试代码单元，该代码单元可能大于方法。通常不可能分别测试setter-getter和构造函数-getter对，这是可以的。您自然会有像“包含插入的元素”和“不包含未插入的元素”这样的测试用例。在这种情况下，我将测试的重点放在修改结构的方法上。在这里，我可能会使用一个单独的测试用例进行contains。

TEST(BinarySearchTree, ContainsInsertedElements) {
    BinarySearchTree t;
    EXPECT_FALSE(t.contains(5)); // precondition

    t.insert(5); // act

    EXPECT_TRUE(t.contains(5)); // assert
}

(再次插入相同元素的另一种情况也有效，还有一个高级别的非单元测试用例，我可以插入多个数字，这应该会产生一个预期的树结构。)

对于contains，我可能切换到更多的白方测试。特别是，insert和common可能有一个共同的查找操作，可以更仔细地进行测试，然后我们可以假设包含的操作可能也是正确的。

本质上，仅仅因为测试主体使用两种方法就复制测试似乎不是一个好主意。测试是代码，“不要重复自己”之类的指导方针仍然适用(在合理的范围内)。此外，重复的测试不会增加价值:如果其中一个失败了，另一个也会增加价值。最好将重点放在被测试单元的更一般的契约上，而不是狭隘地集中于每一种方法，不管它可能是多么的无用。

Answer 2

如果您的测试用例做得很好，则有两个目的：

1. 在将来对代码进行更改时，他们检查现有的功能没有中断；
2. 它们记录了代码的使用方式和行为方式。

如果你只有一张支票，

TEST(BinarySearchTree, Insert) {
    BinarySearchTree t;
    t.insert(5);
    EXPECT_FALSE(t.contains(2));
    EXPECT_TRUE(t.contains(5));
}

然后，它无法实现第二个好处：EXPECT_FALSE(t.contains(2));被隐藏在Insert检查中，因此对用户来说并不明显。

因此，虽然编写这两个测试的代码稍微多一点，但是如果您这样做的话，测试所做的事情就会更加清楚。与只保存几行代码相比，这是一个巨大的优势。