你什么时候达到单位测试过度杀伤？

Question

我目前正在开展一个项目,在那里我使用NUnit进行单元测试,使用Moq进行模拟,使用MSpec编写规范并使用WebAii测试UI.

虽然我总体上享受了这方面的经验,并且充分了解了测试的内容和方法,但我还是想知道这四种工具是否有点落伍.

单元测试是否有点荒谬？有可能过头了吗？在你看来,什么是合理的测试和什么是不必要的细节？

编辑:
要清楚,我所写的测试数量并不是因为我正在使用的工具的广度.四个似乎很多,但如果其他人使用这种阵容效果良好,我想听听它.

Answer 1

可以一次使用许多测试框架吗？

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

那么你什么时候进行单元测试过度杀伤？

您可以快速完成单元测试"过度杀伤",您可能已经达到了它.一般来说,有几种方法可以过度测试,这会破坏TDD,BDD,ADD以及您使用的任何驱动方法的目的.这是其中之一:

当您开始编写其他类型的测试时,就会达到单元测试过度杀伤,就好像它们是单元测试一样.这应该通过使用模拟框架(测试仅隔离到一个类的交互)和规范框架(测试功能和指定的需求)来修复.许多开发人员之间存在混淆,他们似乎认为以同样的方式处理所有不同类型的测试是一个好主意,这会导致一些肮脏的混合.

尽管TDD专注于单元测试,但您仍然会发现自己正在编写功能,集成和性能测试.但是,您必须提醒自己,它们的范围与单元测试有很大不同.这就是为什么有许多测试工具可用,因为有不同类型的测试.使用许多测试框架没有任何问题,并且大多数测试框架彼此兼容.

所以写单元测试时有一对夫妇的甜蜜点考虑编写测试时:

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

单元测试很容易编写,你想写很多.但是如果你编写一个具有太多依赖关系的测试,一旦需求开始改变,你将会得到很多工作.当代码在具有太多依赖关系的单元测试中断时,您必须检查许多类的代码而不是一个且只有一个类.这意味着您必须检查其所有依赖关系,以查看问题所在,这在TDD意义上违背了单元测试的目的.在一个大型项目中,这将是非常耗时的.

这个故事的寓意是,不要将单元测试与集成测试混淆.因为简单地说:它们是不同的.这并不是说其他​​类型的测试很糟糕,但是应该将它们视为规范或健全性检查.仅仅因为测试中断,它们可能不是代码错误的指示.例如:

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

唯一要记住的是以易于区分和发现的方式组织测试.

你需要一直写测试吗？

有时候通常可以省略测试用例,因为通过手动烟雾测试进行验证更容易,并且不需要花费很多时间.在这种意义上的手动烟雾测试是您启动应用程序以自行测试功能或未编码您的东西的其他人的操作.也就是说,如果您要编写的自动化测试是以下所有内容:

• 方式过于复杂和曲折
• 将花费大量的工作时间来写作
• 没有现成的,易于使用的测试框架来处理它
• 不会给予很多回报,例如几乎没有回归的机会
• 可以手动完成,而且比编写自动化测试要少得多

...然后将其编写并作为手动测试用例进行测试.如果测试用例需要几天的时间来编写,手动测试烟雾只需要一分钟,这是不值得的.