单元测试类构造函数

Question

在C++中,如何测试类构造函数？例如:

Class myClass{
    int a;

public:
    myClass(); //Constructor
    void reset(); //resets a to 0;

};

//Constructor defined to initialize a to 0
myClass::myClass(){
    reset();
}

//reset sets a to 0
void myClass::reset(){
    a = 0;
}

我如何测试myClass()构造函数？我无法访问私有数据成员,所以说重置是否有效然后构造函数工作是否有效？

Answer 1

我将把你的问题改写为:我如何测试我的类的属性,这些属性不能直接从我的测试中观察到,因为它们是受保护的还是私有的？以下是我通常会考虑的顺序中的几种可能性:

• 使用assert()将测试的检查部分移动到类中.如果你想测试的是你的构造函数已经成功建立了一些复杂的不变量,那么你可以在构造函数的末尾放置一个assert()来验证该不变量.然后你所要做的就是调用构造函数 - 构造函数中的断言执行测试本来会做的实际检查.如果您在编写代码时习惯性地添加断言,那么断言已经存在(如果断言使您的调试构建太慢,请使用分析器来查明那些实际上存在问题的断言).

• 将要测试的复杂代码段提取到第二个类中.然后,您可以通过其公共接口测试第二个类.即使不考虑可测试性,当提取第二类改进代码时,此选项也很有吸引力.

• 将代码的设计更改为以其他方式更可测试的代码.同样,即使不考虑可测试性,当改变是改进时,这也是有吸引力的.

• 战略撤退.在所有其他条件相同的情况下,孤立地测试代码是好的,但没有法律规定所有代码都必须单独测试.有时候正确的答案是让测试代码作为测试其他东西的副作用.毕竟,该类的所有其他测试都将调用构造函数,因此如果构造函数出现问题,则可能导致其他测试之一失败.以这种方式覆盖所有路径可能更难,并且当您遇到失败时,追踪失败原因会更麻烦,因为现在您不知道问题是构造函数还是正在测试的其他东西.这可能是也可能不是什么大不了的事.孤立地测试这段代码真的值得麻烦吗？考虑到你可以在那个时间使用的其他东西以及这个测试真正找到错误的可能性？代码审查会是一种更有用的方式来花时间吗？还有什么东西可以做得更有用吗？

如果你真的必须测试一些无法用assert()测试的东西,并且没有可接受的重构来提高可测试性,那么仍然有一些选择.我从来没有必要使用它们进行测试,但它们是:

• 使用朋友声明可以让您的测试访问您班级的私人字段.现在,每个类都需要为需要访问的测试维护一个友元声明列表.这可能是一项值得维护的苦差事.

• 维护一个单独的界面供测试使用.有一组方法可以提供所需的访问权限,其名称的前缀如"testOnly".所以在你的情况下,它将是testOnlyGetA().只需要从测试中调用这些方法,您就必须遵守规则,现在需要维护比以前更大的接口.

• #define private public在包含要测试的标题之前,请先捏住鼻子并在测试文件中进行操作.