我们在制作好网站的前端后都需要进行测试，这是
网站建设过程非常重要的一个环节，前端测试仅仅是工具和过程。在本文中尼高小编将分享他关于如何组织测试以及在前端和子系统之间以及不同策略之间找到正确平衡的经验。
我经常遇到前端开发人员、管理人员和团队面临一个重复且合理的困难困境:如何在单元、集成和E2E测试之间组织他们的测试，以及如何测试他们的UI组件。单元测试似乎经常不能捕捉到发生在用户和系统身上的“有趣”的事情，E2E测试通常需要很长时间来运行或者需要一个混乱的配置。
我们不倾向于把我们的前端设计成一个系统，而是一堆组成用户界面故事的组件和功能。由于组件代码主要存在于JavaScript或JSX中，而不是在HTML、JS和CSS之间分离，混合视图代码和业务逻辑代码也比以往任何时候都更有吸引力。当我说“我们”时，我指的是我作为开发人员或顾问遇到的几乎每一个web项目。
当我们来测试这段代码时，我们通常从类似反应测试库它渲染React组件并测试结果，或者我们为配置Cypress使其与我们的项目很好地配合而烦恼，很多时候以错误配置或放弃而告终。当我们与管理人员谈论建立前端测试系统所需的时间时，他们和我们都不知道它需要什么，我们在那里的努力是否会有成果，以及我们构建的任何东西如何对最终产品的质量和构建速度有价值。
如果我们有某种"强制TDD "团队中的(测试驱动开发)过程，或者更糟，一个代码覆盖门，你必须有X%的代码被测试覆盖。作为前端开发人员，我们结束了一天的工作，通过修复散布在几个React组件、定制挂钩和Redux reducers之间的几行代码来修复一个bug，然后我们需要提出一个“TDD”测试来“覆盖”我们所做的事情。当然这不是TDD在TDD中，我们会先编写一个失败的测试。但是在我遇到的大多数前端系统中，没有基础设施来做这样的事情，并且在试图修复关键bug的同时首先编写失败测试的请求通常是不现实的。
为了尊重我们组织的过程，像强制测试规则或CI中的一些代码覆盖门，我们使用Jest或我们手边的任何工具，模仿我们已经改变的代码库部分周围的一切，并添加一个或多个“单元”测试，以验证它现在给出“正确”的结果。
除了测试难以编写之外，它的问题是我们现在已经创建了一个事实上的合同。我们不仅验证了一个函数给出了一些预期的结果，而且我们还验证了这个函数具有测试预期的签名，并且以与我们的模拟相同的方式使用环境。如果我们想要重构那个函数签名或者它如何使用环境，测试将成为一个累赘，一个我们不打算遵守的契约。它可能会失败，即使该功能有效，也可能会成功，因为我们改变了内部的一些东西，并且模拟环境不再与真实环境匹配。
