Question

昨天我把一个班组成了一个有用的任务。我开始进行alpha测试，并且在某些时候意识到我正在为类本身添加与alpha测试相关的方法。它打击了我，他们不属于那里。在经过一些努力之后，我从基类中派生了一个测试类，该类也可以访问受保护的成员。我把所有与测试相关的方法，并在测试课程中设置和拆除，并使基础课程倾斜，并且正如俗话所说的那样。

在这里浏览了一段时间后，我发现一条评论建议使用这种技术，让测试类成为真实类的朋友。

回想起来，这些技巧对我来说应该是显而易见的。

我正在寻找的是专门针对alpha测试/单元测试类的技术，而不会增加被测试类的重量。

您个人使用过哪些技巧并推荐？

Answer 1

单元测试的目标之一是验证类的接口。这意味着，一般来说，你不应该测试你班上肮脏的内脏。单元测试应该与您的类的公共输入和输出交互，并验证行为是否符合预期。因此，您可以更改类的内部实现，而不会影响依赖于它的所有其他对象。显然，我不知道你的情况中的细节，但我会说，作为一般规则，如果你的单元测试试图弄清楚班级的私人细节，那你就做错了。

编辑：另请参阅：This SO question。请注意，它可以完成（最佳答案），但也注意到第二位的答案（以短边距）或多或少与上面提到的相同。

Answer 2

听起来你不想要单元测试，这正确地证明了一个类的接口是有效的。你不应该为了进行单元测试而改变你的课程。如果您正在寻找一种方法来验证对象的内部状态以使其保持一致，那么您应该查看Design by Contract方法，这些方法可以验证对象内部的状态。

Answer 3

那些都很好。我通常也希望测试类不仅是原始的，而且是完全不同的DLL / EXE，以及从编译它的“真正的”DLL / EXE中测试“真正的”编译类。

我发现的另一项技术是在测试工具中重新定义类。完全复制类定义，但将所有内容都公开。这允许测试工具对类进行“白盒”访问，但实际的实现仍然来自真正的类代码。

即

class myClass
{
private:
    int foo;
public:
    myClass() { foo = 0; }
}

然后：

class test_myClass
{
public:
    int foo;
public:
    test_myClass();
};

void test()
{
    myClass *c = new myClass();
    test_myClass *t = (test_myClass*)c;
    // All methods are called on c.
    // White-box access is available through t.
};

哦......而DevStudio 2008现在有一些非常酷的单元测试功能，包括声明'朋友'程序集的功能，它允许白盒访问所有内部类。装配正在测试中。

Answer 4

我做了很多框架构建 - 基本上调用了我想要测试的类/接口。这些课程没有额外的工作。

我还建了几次类，使公共方法变得虚拟。我从那些派生出来并制作了测试类/对象。测试对象方法称为父（真实类）方法，并记录所有调用和结果。这对于日志记录比测试更多，但它也有效。

上面的方法我在关于单元测试之类的所有宣传之前做过。（大约1990年代后期）

当时它对我来说效果很好，但我对Junit / nunit的东西并没有做太多的事情，并且我真的很想让他们在实际项目上发挥作用。

一种方法的样本

类Thing

{...

公共：虚拟DoStuff（）; 。 .. };

类ThingTest：public Thing

{

虚拟DoStuff（）

{

//记录通话和参数。

//调用父

//记录返回值

//返回返回值

}

};

Answer 5

eJames是正确的单元测试需要关注接口，即类的输入产生正确的输出。任何私有或朋友变量都是实现的一部分，未经过特定测试。

如果您在类的私有例程中出错，那么它将显示错误的输出。

测试课程

5 个答案: