在编写单元测试时我应该参考实现吗?

时间:2017-06-28 05:43:30

标签: unit-testing

我被分配了一个关于为一些已经实现的类编写单元测试的任务。

目前我并不是真正了解每个班级的目的。我担心的是,我是否应该(1)深入研究实施,或者(2)只是简单地看一下输入 - 每个类的预期输出(以及它的方法)?

IMO:

(1)有一个优点,我可以看到一些潜在的错误,以便我可以设计可以涵盖这些情况的单元测试。

另一方面,(1)的缺点是(a)我可能会因实施而受到偏见,(b):需要时间。

1 个答案:

答案 0 :(得分:2)

实际上,你做两者

首先,您首先关注被测试类的公开合同。所以是的,看输入/输出应该是你的第一站#34;

你知道 - 理想情况下,你的单元测试不需要任何嘲弄。您创建了一些实例underTest;你叫一个方法;您观察/验证某些行为(例如,根据实际返回值声明预期)。

但当然,有时候值得查看实施细节。

所以,合理的程序是:

  • 写"黑匣子"不了解实施细节的测试(如果可能)
  • 使用报道来了解" good"你的测试涵盖了测试中的课程

根据覆盖范围数字,您可以得出进一步的结论,例如:

  • 你的黑匣子测试不够,你需要添加某些白盒"测试以获得特定方法。含义:你看看被测试的班级,了解它在做什么;以及如何进入重要角落。
  • 您的测试实际上很棒 - 但是在测试的这些类中有未使用的代码。也许这可以删除(删除源代码是你作为软件工程师可以做的第二件事!)

最后:更多的是反模式来创建单元测试(或多或少)重新编程实现。您确实希望避免单元测试除了为生产代码正在进行的调用配置模拟外,别无其他操作。事情是:当您测试实现细节时,任何实现更改(如简单的重构/重新排序)都可能会破坏您的单元测试。