用 Jest 进行前端(反应)快照测试:是为了什么？
用 Jest 进行前端(反应)快照测试:是为了什么？
原文：https://medium.com/hackernoon/front-end-react-snapshot-testing-with-jest-what-is-it-for-7788f7bd5a2e
从 14.0 版本开始，Jest 增加了一个新的快照特性。有一篇博客文章宣布了这一特性，并解释了脸书实施这一特性的原因。但我觉得还是根据自己的经历去探索比较好。
首先，重要的是要强调每种类型的测试都是不同的，都有特定的目的。例如，单元测试验证软件的每个单元都按照预期执行。集成测试确保这些单元能够很好地协同工作。用户界面测试(端到端测试)从用户角度测试应用程序界面。
还有一些技术，像测试驱动开发 (TDD)定义了“何时应该测试”(或者在编码前编写测试)，以及行为驱动开发 (BDD)接近“你为什么编码”(或者编码前的行为和规格)。
回归测试
快照测试与之前的测试类型和技术无关。快照有助于确保某事物的状态在未来不会改变。所以，不可能用快照测试来进行 TDD 或 BDD，因为你应该先写代码，后测试。
快照测试是回归测试的一种，旨在验证之前开发和测试的软件在更改后是否正确运行。
测试声明性接口和集成
下面的购物车物品组件示例经常被测试覆盖。让我们考虑一下。但是首先，请确保您意识到代码是声明性的，没有任何类型的逻辑。
考虑和证明声明性代码的测试是困难的。正如本文所指出的，测试声明性代码的任务以测试声明本身的功能而告终。但是可读性和意图较差。的确，声明性代码实际上是形式规格说明。
BDD 测试用例确保数量和图像出现在界面上是公平的。这两个资产是特性规范的一部分:购物车条目应该有图像和数量。
此外，用快照测试来覆盖这些是没有意义的。当你在将来改变它的时候，你故意这样做。但另一方面，购物车(或其他组件)可以快照其与购物车项目的集成。可能是改了购物车物品的开发者不知道购物车用的。
遗留的和测试不良的代码
依我拙见，一个具有遗留代码库的项目应该是最适合快照测试的。使用这种类型的测试，很容易创建最小的测试代码覆盖率，而不会浪费单元测试的时间。
看一看一个对使用反应和酶的应用程序进行快照测试的例子。注意，我使用了render酶法，而不是shallow或mount，因为我打算测试最终的 HTML 结果。
如果你正在做这样的项目，我祝你好运，也建议你看看类似于 PhantomCSS 的自动化可视化回归测试的工具。
