编写优美的GTest测试案例初稿.docxVIP

编写优美的GTest测试案例使用gtest也有很长一段时间了，这期间也积累了一些经验，所以分享一下。GTest为我们提供了便捷的测试框架，让我们只需要关注案例本身。如何在GTest框架下写出优美的测试案例，我觉得必须要做到：案例的层次结构一定要清晰案例的检查点一定要明确案例失败时一定要能精确的定位问题案例执行结果一定要稳定案例执行的时间一定不能太长案例一定不能对测试环境造成破坏案例一定独立，不能与其他案例有先后关系的依赖案例的命名一定清晰，容易理解案例的可维护性也是非常重要，如果做到上面的8点，自然也就做到了可维护性。下面来分享一下我对于上面8点的经验：1. 案例的层次结构一定要清晰所谓层次结构，至少要让人一眼就能分辨出被测代码和测试代码。简单的说，就是知道你在测什么。由于是进行接口测试，我已经习惯了如下的案例层次：DataDefine我会将测试案例所需要的数据，以及数据之间的联系全部在预先定义好。测试数据与案例逻辑的分离，有利于维护和扩展测试案例。同时，GTest先天就支持测试数据参数化，为测试数据的分离提供了进一步的便捷。什么是测试数据参数化？就是你可以预先定义好一批各种各样的数据，而你只需要编写一个测试案例的逻辑代码，gtest会将定义好的数据逐个套入测试案例中进行执行。具体的做法请见：玩转Google开源C++单元测试框架Google Test系列(gtest)之四 - 参数化SUTSUT，即system under test，表明你的测试对象是什么，它可以是一个类(CUT)，对象(OUT)，函数(MUT)，甚至可以是整个应用程序(AUT)。我单独将这个层次划分出来，主要有两个目的：明确的表示出你的测试对象是什么为复杂调用对象包装简单调用接口明确表示测试对象是什么，便于之后对测试案例的维护和对测试案例的理解。同时，对于一些被测对象，你想要调用它需要经过一系列烦琐的过程，这时，就需要将这一烦琐的调用过程隐藏起来，而只关注被测对象的输入和输出。TestCase测试工程中，必须非常明确的表示出哪些是测试案例，哪些是其他的辅助文件。通常，我们会在测试案例的文件名加上Test前缀(或者后缀)。我建议，将所有的测试案例文件或代码放在最显眼的地方，让所有看到你的测试工程的人，第一眼看到的就是测试案例，这很重要。Checker对于一个复杂系统的接口测试，仅仅坚持输入和输出是远远不够的。比如测试一个写数据库的函数，函数的返回值告诉你数据已经成功写入是远远不够的，你必须亲身去数据库中查个究竟才行。因此，对于某一类的测试案例，我们可以抽象出一些通用的检查点代码。如果做到上面的分层，那么一个测试案例写出来的结构应该会是这个样子：TEST(TestFoo,?JustDemo){????GetTestData();?//?获取测试数据????????CallSUT();?//?调用被测方法????CheckSomething();?//?检查点验证}这样的测试案例，一目了然。2. 案例的检查点一定要明确一定要明确案例的检查点是什么，并且让检查点尽量集中。有一个不好的习惯就是核心的检查点在分布在多个函数中，需要不断的跳转才能了解到这个案例检查了些什么。好的做法应该是尽量让检查点集中，能够非常清晰的分辨出案例对被测代码做了哪些检查。所以，尽量让Gtest的ASSERT_和EXPECT_系列的宏放在明显和正确的地方。3. 案例失败时一定要能精确的定位问题测试案例失败时，我们通常手忙脚乱。如果一个测试案例Failed，却不能立即推断是被测代码的Bug的话，这个测试案例也有待改进。我们可以在一些复杂的检查点断言中加入一些辅助信息，方便我们定位问题。比如下面这个测试案例：int?n?=?-1;bool?actualResult?=?Foo::Dosometing(n);ASSERT_TRUE(actualResult)如果测试案例失败了，会得到下面的信息：Value?of:?actualResultActual:?falseExpected:true这样的结果对于我们来说，几乎没有什么用。因为我们根本不知道actualResult是什么，以及在什么情况下才会出现非预期值。因此，在断言处多加入一些信息，将有助于定位问题：int?n?=?-1;bool?actualResult?=?Foo::Dosometing(n);ASSERT_TRUE(actualResult)??LCall?Foo::Dosometing(n)?when?n?=???n;4. 案例执行结果一定要稳定要保证测试案例在什么时候、什么情况下执行的结果都是一样的。一个一会成功一会失败的案例是没有意义的。要保证案例稳定性的方法有很多，比如杜绝案例之间的影响，有时候，由于前一个案例执行完后，将一些