在什么时候你达到了单元测试过度的程度?

一次使用多个测试框架可以吗?

一些开源软件项目确实使用了几种测试框架。如果项目的开发人员不想进行他们自己的模拟,一个常见的设置就是使用单元测试框架和模拟框架。

那你什么时候到达 单元测试过量 ?

“杀伤力过大” TDD BDD , ADD

当您开始像编写单元测试一样编写其他类型的测试时,就达到了单元测试过度。这应该通过使用模拟框架(只测试隔离到一个类的交互)和规范框架(测试特性和指定需求)来解决。许多开发人员对此感到困惑,他们似乎认为以相同的方式对待所有不同类型的测试是一个好主意,这导致了一些问题 .

即使TDD专注于单元测试,您仍然会发现自己正在编写功能、集成和性能测试。然而,你必须提醒自己 范围大不相同 来自单元测试。 使用许多测试框架并没有什么错,它们中的大多数是相互兼容的。

因此,在编写单元测试时,有一个 couple of sweet spots 编写测试时要考虑:

unit test                 dirty hybrids               integration test
---------                 -------------               ----------------
* isolated                                            * using many classes 
* well defined                  |                     * tests a larger feature
* repeatable                    |                     * tests a data set
                                |
    |                           |                              |
    |                           |                              |
    v                           v                              v

    O  <-----------------------------------------------------> O 

    ^                           ^                              ^
    |                           |                              |

sweet spot              world full of pain                sweet spot

单元测试很容易编写,您需要编写很多单元测试。但是,如果您编写的测试具有太多的依赖项,那么一旦需求开始改变,您将完成大量的工作。当单元测试中有太多依赖项的代码中断时,您必须检查多个类的代码,而不是 唯一的

这个故事的寓意是,不要混淆单元测试和集成测试。因为简单地说: 他们是不同的

• 如果 如果出现中断,您的某些需求可能存在问题,需要修改需求、删除、替换或修改测试。
• 性能测试 中断,取决于它是如何实现的该测试的随机性可能会让您认为它只是在该实例上运行缓慢。

要记住的唯一一件事是以一种易于识别和发现的方式组织测试。

有时省略测试用例是可以的,通常是因为通过手动验证 smoke testing 全部的 其中:

• 没有现成且易于使用的测试框架来处理它
• 可以手动完成,比编写自动测试要省力得多

然后编写它并将其作为手动测试用例进行测试。如果编写测试用例需要几天时间,而手动测试只需要一分钟,那就不值得了。

只要每个新的测试用例测试不同的东西,您就可以了。

我通常测试边界。如果我写了一个fibuncai函数,我会测试它的值-1,0,1,10和一个整数的Maxvalue。测试20或509不会测试任何尚未涵盖的内容。

http://en.wikipedia.org/wiki/Test-driven_development )

没有过度测试这回事!当然,你不想这样做。给定方法

public void tripleInt(int i);

编写高粒度的单元测试有时是一种过分的工作。

单元测试的要点是:

1. 测试给定装置a的一组代表性输入(如果一个装置测试包含装置a的较大装置B,则被认为代表装置B的一组输入可能不会产生装置a的一组代表性输入)。
2. 以最大精度确定代码中断的位置。

但是如果你有一个较大的单元,包含几个小单元,那么对于较大的单元,你有一组输入,这会导致较小单元也有代表性的输入,并且如果较大的单元断裂,很容易确定断裂点的确切位置,几乎没有理由为每个较小的单元编写单元测试。