Ç ontinuous我Continuous Integration 和Continuous Delivery管道，也被称为CI / CD，
代码格式和整理Linting
- ESlint for linting，它附带一组规则来编写正确的Javascript，并且可以根据您自己的团队的需要来定制这些规则。另外，如果您需要更具体的内容，则可以构建自己的ESLint规则，这是我在此处写的，这是一个有趣的练习，涉及抽象语法树（AST）。
- Prettier的格式。在过去的几年中，它已成为Javascript开发人员的事实上的格式化工具。我在项目和编辑器中进行了设置，以一种保存文件的方式自动为我设置格式。
单元测试
- @ testing-library / react ：如果您想随时间编写可维护的测试，而不必担心实现细节。我主要使用它来渲染单个组件并对其进行测试。
- @ testing-library / react-hooks：该库为您提供了测试自定义钩子所需的所有工具。
- @ testing-library / jest-dom：此软件包为您提供了额外的DOM元素匹配器，以使您的测试更加易于编写和阅读。
@ testing-library维护人员还提供了许多其他软件包，无论框架如何（Svelte，VueJS等），它们都将帮助您测试应用程序。
集成测试
- Jest：您可以使用Jest@testing-library/react和我们之前提到的所有出色工具编写非常高级的集成测试。我最近开始使用msw模拟我正在测试的视图取决于不同的API。
- 赛普拉斯（Cypress）：它提供了一种巧妙的方式来编写固定装置和模拟API端点，从而运行一些集成测试。我主要使用它来验证一些与浏览器相关的行为，例如：是否将正确的查询参数传递给URL？是否可以通过将这组参数添加到URL来以特定状态加载视图？是否在本地存储中设置了一组特定的值？
端到端测试
强烈建议您以 赛普拉斯 为起点。赛普拉斯团队已经建立了最便捷的方式来编写e2e测试，并获得了最佳的文档和社区支持。
在编写e2e测试中一直使用的技巧：
- 每个测试都应该是 独立的。对于具有测试A，B和C的给定套件，整个套件会失败，因为测试A失败可能会导致测试B和C的其他问题很难发现。我尽力保持每个测试尽可能独立，以免给我带来麻烦调试损坏的测试时需要花费时间和精力。
- 在测试之前触发API调用，以创建测试所需的所有对象（待办事项，帖子等）。对于应用程序中的给定对象，您可能具有“创建”，“读取”和“更新”流程，我想测试所有这三个流程。但是，如果“读取”和“更新”流程依赖于“创建”测试的成功，则它们不能是独立的。因此，我倾向于创建自定义命令来调用相关的API，以创建执行测试之前所需的对象。
- 在团队中推广良好的测试习惯，经常运行（在下一部分中将进行介绍），在它们破裂后立即对其进行修复，收集要编写的测试列表并确定其优先级。
- 如果您的代码库中当前有0个e2e测试，并且不知道首先编写哪个测试： 首先编写一个可以验证应用程序中大多数错误或脆弱功能的测试。此单一测试将立即对您的产品产生积极影响。如本文前面所述，通过使产品比编写测试之前更好来强调CI / CD和测试的影响。您的组织和用户将不胜感激。
辅助功能测试和审核
这是CI / CD管道的最后也是最重要的部分。通常，它也是最复杂的，因为要保证您的前端项目100％可访问性并不是一件容易的事，但这是每个人都应努力的事情 。
这里有一些工具可以作为自动CI / CD管道的一部分运行，我用它们来 指导可访问性工作：
- Lighthouse CI：这是一套工具，可帮助您审核性能，可访问性以及您的应用是否遵循最佳实践。我基本上使用此工具来 保持稳定，并确保事情不会随着时间的推移而恶化。它使您可以汇总“性能和可访问性预算”和阈值。如果您的分数低于目标预算，它将失败。这可能值得一整篇文章，但与此同时，您可以查看其包含示例Github工作流程的文档，并将其轻松集成到CI / CD管道中。
- 赛普拉斯Ax：此软件包可在赛普拉斯之上运行，并允许您运行一系列针对可访问性的测试套件。它帮助我发现了Lighthouse CI将跳过的一些更复杂的可访问性问题。
自动化：何时以及如何运行测试并发布
现在我们已经编写了一些单元，集成，端到端测试，并放置了用于跟踪可访问性问题的工具，是时候讨论自动化了。您的团队的目标应该是尽可能地自动化，从运行测试到预览部署，再到部署到生产。 CI / CD管道中剩下的唯一手动步骤应该是代码审查。
自动化的主要工具，使用Github CI，Actions和Workflows，并且它一直在发挥作用！
发布
我们要自动化的最后一件事是 发布过程。您不需要以特定顺序手动运行20个脚本来将应用程序从主分支转移到生产环境。为此，我倾向于在Github存储库中使用所谓的 release分支， 并且每次将main分支合并到release分支时都运行自动脚本 。您还可以在其他事件上运行自动脚本，例如在 标记发布时，或者如果您的组织具有一致的发布节奏，甚至可以安排排定的部署。在这一点上，这取决于您的团队或组织以及要发布的方式/时间。