如何为需要复制被测代码的代码编写测试?

时间:2009-06-01 17:29:30

标签: unit-testing

我正在努力将尽可能多的逻辑移出自定义控件,以便对其进行单元测试以减少手动测试负担。我遇到的问题是被测方法会产生复杂的结果;编写一个计算结果的测试用例将涉及将基本上被测试的代码写入测试本身。

例如,我有一个GeometryGenerator类,它根据类的属性创建WPF几何。在一种配置中,生成由PathGeometry组成的ArcSegment。我可以根据测试参数计算弧的属性应该是什么,但是这个计算与我试图测试的代码相同。这似乎会使测试失效;如果计算中存在错误,则测试中会出现错误,如果计算中的计算发生变化,则可能需要在测试中进行更改。

我该怎么办?我提出的唯一方法是手工计算我的测试用例的结果并将这些值硬编码到测试中。这是一种可接受的方法(如果我在实施之前编写测试,它似乎就是我做过的)?

4 个答案:

答案 0 :(得分:4)

  

我提出的唯一方法是手工计算我的测试用例的结果并将这些值硬编码到测试中。这是一种可接受的方法(如果我在实施之前编写测试,它似乎就是我做过的)?

是的,这是典型的。出于单元测试的目的,您必须假设您用于计算结果的公式是正确的。这是您正在测试的软件实现。

您预先计算了一些手工计算的结果,以确保您没有使用被测代码来生成测试数据(单元测试中的一个非常糟糕的错误)。只需确保记录您的测试用例,以便了解期望值代表什么以及它们来自何处。

答案 1 :(得分:1)

手动计算和硬编码在生产代码中很糟糕,但对良好的单元测试至关重要。

您通常希望为代码的每个“状态”编写一个测试。例如,我经常用正输入,负输入和零输入编写测试,以确保代码按预期工作。

答案 2 :(得分:1)

通常情况下,我会制作一个自我记录但却是硬编码的神奇数字,例如

const int expectedResult = 2 * 4 / someConstant; //也许是评论。

测试的读者可以推断出值是什么,或者您可以在必要时添加额外的注释。

答案 3 :(得分:0)

“单元测试”应该只是测试一个单元。理想情况下,您可以为GeometryGenerator分别进行单独的单元测试,为PathGeometry课程分别进行单独测试,为ArcSegment分别进行单独测试等。

通过单独测试每个单元,当您使用给定的一组输入调用给定的操作时,您可以对它们的行为有一定的信心(GeometryGenerator在{中的字段时的行为方式{1}}设置为1,与相同字段设置为0时的行为方式相比,等等。

如果您的单元测试开始看起来像是在复制现有代码以测试某个功能,那么我担心您的单元测试错误,并且有一个更简单,更有效的解决方案。