我们想提请您注意我们预购中的另一种新颖性-一本有关单元测试的书。
今天的出版物的作者以前端为例，简要而清晰地谈论了单元测试和TDD的优点。
享受阅读！
单元测试是每个开发人员都应该采用的最重要的方法之一。但是，我见过很多项目，很难将单元测试付诸实践。有许多的原因。例如，有人可能会说您需要专注于开发功能，在这种情况下编写单元测试是一个严重的额外负担。其他人会注意到，测试代码并不是一件容易的事，因为代码本身很复杂。在这两种情况下，都没有抓住重点。
我记得这个表达：考虑到是否有时间编写单元测试时，请考虑是否会由于其中的错误和问题而有额外的时间两次处理同一代码。
编写可测试的代码
首先，让我们定义哪些常见错误使测试代码变得更加困难。当涉及到前端测试时，我所知道的最困难的问题之一就是测试用户界面组件。在这种情况下，我遇到的主要问题是：碰巧这些组件过于“智能”，并且悬挂了对其他代码片段的依赖，例如来自API调用，数据加载，事件处理，业务逻辑实现的依赖。许多开发人员不喜欢为此类“繁重”的组件编写测试。
解决此问题的最简单方法是将组件分为逻辑和表示形式。通过这种分离，您可以测试表示组件如何遵守表示逻辑，执行事件处理和呈现，并分别专注于测试负责该逻辑的组件中的业务逻辑。
使您的组件可测试也是确保它们独立，可重用和方便一起使用的好方法。这绝对是必不可少的，尤其是在使用流行的工具和平台（例如Bit（Github））。通常，Bit将分别显示和测试您的每个组件，然后才将它们发送到共享集合，从而确保它们确实可重用-否则，使它们可分离是什么意思。
示例：探索在Bit.dev上共享的可重用React组件
恶性循环：如果不编写单元测试，会发生什么
根据我在没有正确应用单元测试的团队中的经验（即，不使用测试覆盖率作为度量标准），或者太晚或从一开始就开始进行单元测试，但是没有学习如何实践。造成这种情况的原因可能很多，但我将举几个例子，使您更容易确定哪个案例与您的案例最相似。
在开发过程中我们如何测试代码
我认为，除非坚持使用测试驱动的开发（TDD），否则只要前端不断加载到浏览器中，就可以开发功能。您需要专注于可视化用户界面中发生的功能和交互，因为这是客户端开发的本质。
只有在那之后，当所有功能都已经起作用时，重点才转向单元测试。
这是您必须面对的主要问题：编写单元测试是在功能开发完成之后执行的另一项工作。这种方法给人的印象是，单元测试是在现成功能开发的基础上执行的附加任务。
由于此问题的表述方式，产品所有者和开发人员都将单元测试分类为成本。
但是，如果您坚持使用TDD，那么一切都会完全相反。由于测试用例是预先编写的，因此我们不必通过不断地可视化更改来检查所有内容，因为在开发过程中我们有不同的方法来检查代码。在这种情况下，主要的验证工具是编写将通过单元测试用例的代码。
因此，我相信在进行单元测试之前，TDD的实践是最重要的阶段。
单元测试运行的频率
您可能想知道运行单元测试如何影响单元测试的编写方式。例如，假设您有一套完整的测试。您不时驱逐它。因此，开发人员很少会相信它的用处。此外，即使发现测试失败，也为时已晚。
因此，至少在拉取请求构建的每个阶段都要运行单元测试，这一点很重要。通过遵循来自DevOps的这种做法，我们确保添加的每个新代码块都经过一组单元测试。即使需要更改特定的情况，开发人员也会在代码合并之前执行此操作。
通过测试衡量代码覆盖率的频率
与测试执行一样，此度量在心理上也很重要，对于开发人员判断他们是否准备足够的测试用例以覆盖所有编写的代码也很重要。
在这种情况下，我认为仅凭仪表板是不够的，您可以在其中查看单元测试的范围。但是，如果可以在添加新代码时添加一个度量标准，从而检查测试覆盖范围，那么这样的选择将更方便获得即时反馈。我们甚至可以制定规则，要求添加到数据库中的任何新代码都应包含80％的测试。将此验证添加到拉取请求的构建过程中是最合适的。
由于开发人员会收到有关其代码的单元测试范围的即时反馈，因此他们可以根据需要自由采取措施以覆盖此类范围。
走出这个圈子
如果您已经陷入这种恶性循环，那么摆脱这种恶性循环的最佳方法就是加强上述做法。由于以上内容是关于频繁测试以验证新添加的代码以及测试新代码的覆盖范围，因此您可以开发适合于任何添加或更改代码操作的过程。
在您必须编写新代码之前，您极不可能有足够的时间立即用测试覆盖所有旧代码（除非项目本身是完全新的）。因此，根本不要指望这一点，因为从业务角度来看，这是不切实际的。同时，您可以进行定期测量，并通过测试策略性地覆盖旧代码的某些部分。最重要的是，您必须培训所有开发人员以遵循这种做法。同样重要的是，要学会如何将这项工作视为一项成本，并向所有项目所有者传达编写单元测试的重要性。否则，许多人，尤其是非技术人员可能会认为单元测试是一项额外的工作，而不是花时间开发新功能。
那么，所有这些工作的真正价值是什么？
单元测试在许多方面都很有用。如果正确应用，它们将有助于减少代码中的缺陷数量，在测试现有功能时起保险作用，在重构代码时不会受到损坏，还有助于使总体生产率保持较高水平。
通过查看单元测试中涵盖的代码，每个人都可以看到它看起来有多自信。因此，让我们通过采用DevOps实践来填补空白并回到正轨，习惯于编写良好的单元测试，同时还要坚持测试驱动的开发。