我们为什么要测试- 通过测试驱动开发来加快速度
众所周知，单元测试为我们提供了某种安全网。他们给我们一个程序，我们可以用它来验证一个系统按照它应该的方式工作 - 特别是在我们进行修改或扩展之后。
通过编写这些测试，你正在做很多工作。如果您认为在维护和扩展工作中真正的好处来自于这个角度，那么您将看到测试是美化或清理的一部分。
在本文中，我想说明的是，在通用Web应用程序的上下文中，典型的验证过程需要比您想象的更长的时间，并且在实际代码之前编写测试会让您更快地完成工作。
您可能认为手动检查速度很快
验证常见Web应用程序修改的常用方法是验证其在浏览器中的行为，就像最终用户会这样做。这意味着你改变了代码，重新加载浏览器，点击一个按钮，看看是否发生了预期的结果。
这个过程的持续时间很大程度上取决于你的环境和你正在使用的应用程序的部分。如果你“幸运”地使用像Angular和Spring这样的框架，那么他们支持大型项目的能力在每次引导和编译时都会付出代价。考虑这个乐观的例子：
10秒自举
5秒编辑
5秒重新加载和测试
所以我们已经有20秒的时间进行手动检查了。这假定您的客户端和服务器端构建工具（如Webpack和Maven）已经过优化。
但其他事情花费的时间比您想象的要长
但是，其他事情经常会延长验证时间。有时候，我们的开发人员在第一次运行时忽略了拼写错误 并在第二。（或第三！）每一个乘以检查代码的时间。
考虑一个更严重的情况，即您在网上商店中开展某种付款功能。检查按钮是否触发适当的操作可能需要很少的时间。但是，包含填写字段的典型结账过程将需要更多。如果你正在从事长时间工作，那很容易超过一分钟。
你可能会认为使用解释型语言可能会加快速度。确实如此，但重要的是，您最终可以轻松完成手动测试循环，每个循环都会持续一分钟，多次。这只是为了验证一些代码行是否具有预期的效果。
TDD加快了速度
正确地做TDD - 先写测试，然后写代码 - 带给你强有力的地位，你几乎可以在几秒钟内运行任何特定部分的隔离代码。
记住单元测试只测试一个类。这个类的所有依赖关系都被模拟 - 特别是对于数据库，文件系统或网络等I / O操作。
用这些测试替代手动验证可显着提高速度。您最终还会得到更高质量的代码，但在更高版本中会更多。最后的验证运行将是手动的。这就是你实际检查是否它们应该是浏览器中最终用户的地方。
是的，即使是那些特殊情况
你总是可以想出一些情况，你发现它应用TDD完全违反直觉。
想想我称之为“实验性工作” - 试验中必须要做的事情，以了解如何使用您不熟悉的图书馆或服务。您已经在处理未知组件。为什么通过在主代码中引入测试框架层使其更加复杂？
或者考虑一下通常在前端部分工作的Web应用程序的开始阶段 - 主要是HTML和CSS，只有一小部分服务器端代码只将数据从数据库“移动”到浏览器。
在这两种情况下，你都应该从一开始就应用TDD。为“实验性工作”创建单元测试可以让您更快地完成反复试验，并为您提供一个随时可以返回的工具集。您的“将数据从数据库移动到浏览器”代码将会及时增加，从而导致无法运行彼此隔离的代码部分的无法测试的代码库。你将不得不自己做耗时的手动测试。
TDD值得努力
您有责任设法找到可测试的代码并将其集成到您的工作流程中。有人以你为专家来支付你的费用。那个人不明白你为什么坐在那里等待一个应用程序启动或点击按钮 - 这是一个不是那么高技能的人可以做的。
编写单元测试正确的方法是您通常不会在大学或普通编程教育中学习的技能。这很难第一次，也将需要几个小时，但你会很快看到第一个结果，永不回头。
从一开始就投资于良好的单元测试，并从第一次提交的模块化应用程序开始，节省您的时间。