前端测试是
网站建设过程中一个非常重要的环节，我们不倾向于将前端编写为一个系统，而是将其编写为构成用户界面故事的一组组件和功能。由于组件代码主要存在于 JavaScript 或 JSX 中，而不是在 HTML、JS 和 CSS 之间分离，混合视图代码和业务逻辑代码也比以往任何时候都更有吸引力。当我说“我们”时，我指的是我作为开发人员或顾问遇到的几乎每个网站建设项目。
我经常遇到前端开发人员、管理人员和团队面临重复且合理困难的困境：如何在单元、集成和 E2E 测试之间组织他们的测试，以及如何测试他们的 UI 组件。当我们开始测试这段代码时，我们通常从渲染 React 组件并测试结果的React 测试库之类的东西开始，或者我们热衷于配置 Cypress 以很好地与我们的项目一起工作，但很多时候最终会出现配置错误或放弃。当我们与管理人员谈论建立前端测试系统所需的时间时，他们和我们都不知道它究竟需要什么，我们在那里的努力是否会取得成果，以及我们构建的任何东西对测试质量有何价值最终产品和建造速度。
如果我们在团队中有某种“强制 TDD”（测试驱动开发）流程，或者更糟糕的是，有一个代码覆盖门，你必须让 X% 的代码被测试覆盖，情况会变得更糟。我们以前端开发人员的身份结束了这一天，通过修复散布在多个 React 组件、自定义钩子和 Redux reducer 中的几行代码来修复错误，然后我们需要提出一个“TDD”测试来“覆盖”什么我们做到了。在 TDD 中，我们会首先编写一个失败的测试。但是在我遇到的大多数前端系统中，没有基础设施可以做这样的事情，并且在尝试修复关键错误时首先编写失败测试的请求通常是不现实的。
除了测试难以编写之外，它的问题在于我们现在已经创建了一个事实上的合约。我们不仅要验证一个函数是否给出了一些预期的结果，而且我们还要验证这个函数是否具有测试所期望的签名，并以与我们的模拟模拟相同的方式使用环境。如果我们想要重构该函数签名或它如何使用环境，那么测试将变得沉重，这是我们不打算保留的合同。即使该功能有效，它也可能会失败，它可能会成功，因为我们在内部进行了更改，并且模拟环境不再与真实环境匹配。
