Javascript单元测试-模拟还是夹具？

Question

对某个猫头鹰感兴趣..。

我正在将JS的单元测试引入到一个团队中，它将主要是带有许多dom交互和更新的测试模块。

传统上，在测试库(如jquery )时，我总是使用模拟和间谍，但由于这是一个新的单元测试团队，我认为补丁可以帮助它们更快地启动和运行。

我对固定装置的使用有以下几点担心：

• 测试可能会变得更像集成测试--这是我们已经拥有的。
• 失去了单元测试所鼓励的更好的编写、结构化、抽象代码的好处。
• 固定装置会减慢测试的速度。
• 固定装置的维护可能成为一种隐藏的开销。

但很想听听别人的意见。

提前感谢

Answer 1

实际上，这样的设备并不是运行单元测试的好方法。单元测试的目标是独立于其余代码和环境来测试代码的一个非常特定的(通常是非常小的)部分。通过使这些测试依赖于网页的特定状态，您将失去测试的“单元”方面，这意味着您更愿意使用系统测试和集成测试。

关于测试的速度方面，你也是对的。DOM的速度非常慢，所以如果您的测试严重依赖DOM，那么就不要指望在一秒钟内运行数千个DOM。

同样正确的是，固定装置的维护可能是一项困难的任务。本质上，如果您的web应用程序的HTML结构发生了变化，您必须在可能的每个夹具中反映这一点。如果夹具是手工编写的，那么您将浪费大量时间来完成这些工作。如果生成了固定装置，那么您可能会浪费大量的时间来调整生成器本身。

当您的方法是在测试(至少是测试)还是不测试任何东西之间做出选择时，您的方法的好处就变得显而易见了。如果项目在时间压力下，夹具可能是一个很好的选择，向您的团队介绍自动化测试。

• 如果项目足够小，这样的测试可能是您唯一需要的:添加单元测试不会带来太多的长期影响，并将在短期内影响项目。
• 如果项目很大，但是没有时间开发完整的单元测试，那么就从系统测试开始。一旦有了足够的分支覆盖率，您就可以专注于新代码、覆盖率最少的代码和添加单元测试最多bug的代码，逐个类进行测试。

一个重要的好处是，如果您的代码库没有很好地为单元测试设计，那么现在添加它们将需要重构，而重构又可能生成回归。如果您已经使用了足够多的系统测试，那么在以后添加单元测试时，您的团队可能会更乐于进行重构，因为他们知道他们有系统测试来检测至少一些回归。