使用亚马逊 CodeCatalyst 报告保持代码质量

亚马逊 CodeCatalyst 报告包含有关工作流程运行期间发生的测试的详细信息。您可以创建单元测试、集成测试、配置测试和功能测试等测试。您可以使用测试报告来帮助解决工作流程中的问题。

简介

在本系列的前几篇文章中，我讨论了阅读 吉恩·金（ Gene Kim ）的《 独角兽计划 》 ，以及主角马克辛在加入新团队后如何应对复杂的软件开发生命周期（SDLC）。她遇到的挑战之一是，如果没有自动测试机制，就很难运送安全、可运行的代码。引用 Gene Kim 的话说：“如果没有自动测试，我们编写的代码越多，测试所需的钱就越多。”

软件开发人员知道，应不惜一切代价避免将易受攻击或无法运行的代码运送到生产环境；金钱影响很大，对团队士气造成的损失可能更大。在 SDLC 期间，开发人员需要一种方法来轻松识别和解决代码中的错误。

在这篇文章中，我将重点介绍开发人员如何无缝运行测试作为工作流程操作的一部分，以及如何使用Amazon CodeCatalyst配置单元测试和代码覆盖率报告。我还将概述开发人员如何访问这些报告以深入了解他们的代码质量。

先决条件

如果您想按照本演练进行操作，则需要：

• 拥有 A WS 生成器 ID 用于登录 CodeCatalyst。
• 属于 CodeCatalyst 空间，并在该空间中为您分配空间管理员角色。 有关更多信息，请参阅在 C odeCatalyst 中 创建空间 、 管理空间成员和 空间管理员 角色。
• 拥有一个与您的空间关联的 亚马逊云科技 账户，并在该账户中拥有 IAM 角色。有关角色和角色策略的更多信息，请参阅 创建 CodeCatalys t 服务角色。

草率排练

与CodeCatalyst系列的前几篇文章一样，我将使用现代三层Web应用程序蓝图。蓝图提供示例代码和 CI/CD 工作流程，可帮助您在编程语言和架构的不同组合中轻松入门。要继续操作，你可以重复使用之前创建的项目，也可以参考 之前介绍如何使用三层蓝图创建项目的文章 。

部署 项目 后，Cod eCatalyst会打开项目概述。此视图显示了来自项目源存储库的 README 文件的内容、工作流程运行、拉取请求等。源存储库和工作流程是由项目蓝图为我创建的。要查看源代码，我 从左侧导航栏中选择 代码 → 源存储库 。然后，我从源存储库列表中选择存储库名称链接。

图 1。包括 Mythical Mysfits 源代码在内的源存储库列表。

从这里我可以查看分支数量、工作流程、提交、拉取请求和该存储库的源代码等详细信息。在这篇演练中，我重点介绍了 CodeCatalyst 的测试能力。该项目已经包括蓝图创建的单元测试，所以我将从那里开始。

从 文件 列表中，导航到 Web → src → 组件 → __tests__ → theG rid.spec.js。 该文件包含前端单元测试，这些测试仅检查 “好”、“中立”、“邪恶” 和 “合法”、“中立”、“混乱” 等字符串是否已在网页上呈现。花点时间检查一下代码。我将在整个演练中使用这些测试。

图 2。对前端进行单元测试，测试字符串是否已正确呈现。

接下来，我导航到执行单元测试 的工作流程 。在左侧导航栏中，选择 C I/CD → 工作流程。 然后，找到 A pplicationDeploymentPipelin e ，展开 “ 最近运行 的版本”，然后 选择 “ 可视 ” 选项卡显示构成此工作流程的基础 YAML 文件的图形表示。它还详细介绍了启动工作流程运行的内容、启动时间、完成所需的时间、源存储库以及工作流程是否成功。

图 3。部署工作流程将在可视设计器中打开。

工作流程由一个源和一个或多个操作组成。我在 之前的一篇文章 中查看了后端的测试报告。因此，我将在这里重点介绍前端测试。选择 build_and_test_fronten d 操作以查看有关该操作运行的内容、其配置详细信息及其生成的报告的日志。 我对 “报告 ” 选项卡下的 单元测试 和 代码覆盖率 报告特别感兴趣：

图 4。显示线路和分支机构覆盖范围的 “报告” 选项卡。

选择报告 unitTests.xml （你可能需要滚动）。在这里，你可以看到这份具体报告的概述，包括通过率、时长、测试套件以及这些套件的测试用例等指标：

图 5。前端测试的详细报告。

该报告已通过所有检查。为了使这份报告更有趣，我会故意编辑单元测试以使其失败。首先，导航回源存储库并打开 Web → src → components→ __tests__→thegrid.s pec.js。 此测试用例正在寻找字符串 “Good”，因此将其改为 “最佳” 并提交更改。

图 6。前端单元测试代码变更。

这将自动启动新的工作流程运行。导航回到 CI/CD → 工作流程 ，您可以看到新的工作流程正在运行中（大约需要 7 分钟才能完成）。

完成后，你可以看到 build_and_test_f rontend 操作失败了。再次打开 unitTests.xml 报告，可以看到报告状态为 “ 失败 ”。请注意，此测试的最低通过率为 100%，这意味着如果本单元测试中的任何测试用例失败，则构建将完全失败。

有一些配置这些最低值的方法，在查看代码覆盖率报告时将对此进行探讨。要查看有关此报告中错误消息的更多详细信息，请选择失败的测试用例。

图 7。测试用例失败错误消息。

正如预期的那样，这表明测试正在寻找字符串 “Good”，但它却找到了字符串 “Best”。在继续之前，我返回到 theGrid.spec.js 文件并将字符串改回 “良好”。

CodeCatalyst还允许我指定代码和分支覆盖标准。覆盖率是一项指标，可以帮助您了解对来源进行了多少测试。这可确保在将源代码发布到生产环境之前经过正确测试。没有为前端配置覆盖范围，因此我将检查后端的覆盖范围。

我选择左侧导航栏 上的 报告 ，然后打开名为 backend-coverage.xml 的报告。您可以查看线路覆盖范围、覆盖的行数、已扫描的特定文件等详细信息。

图 8。代码覆盖率报告成功。

线路覆盖率最低设置为70％，但当前的覆盖范围为80％，因此成功了。我想推动团队继续改进，因此我将编辑工作流程，将最低阈值提高到90％。 导航回 C I/CD → 工作流程 → 应用程序部署管道 ，选择编辑按钮。 在 “可视” 选项卡上，选择 build_backend。在 “ 输出 ” 选项卡上，向下滚动到 “ 成功标准 ”，然后 将 “ 线路覆盖率 ” 更改 为 90% 。

图 9。配置代码覆盖成功标准。

在右上角，选择 提交 。这会将更改推送到存储库并开始新的工作流程运行。运行完成后，导航回代码覆盖率报告。这次，你可以看到它报告了未能达到 线路覆盖 的最低阈值 。

图 10。代码覆盖率报告失败。

还有其他成功标准选项可供试验。要了解有关成功标准的更多信息，请参阅 配置测试成功标准 。

清理

如果您一直遵循此工作流程，则应删除部署的资源，以免继续产生费用。首先，删除 CDK 在启动蓝图时关联的 亚马逊云科技 账户中使用 亚马逊云科技 CloudFormation 控制台部署的两个堆栈。 这些堆栈将使用像 Mysfitsxxxxxwebstack 和 Mysfits xxxxAppstack 这样的名称。 其次，通过导航到项目设置并选择 “删除项目”，从 CodeCatalyst 中删除该项目。

摘要

在这篇文章中，我演示了Amazon CodeCatalyst如何帮助开发人员快速配置测试用例、运行单元/代码覆盖率测试以及使用CodeCatalyst的工作流程操作生成报告。作为软件开发团队，您可以使用这些报告来遵守您的代码测试策略。我还概述了如何使用成功标准来影响工作流程中的构建结果。在 下一篇文章 中 ，我将演示如何配置CodeCatalyst工作流程和集成软件组合分析（SCA）报告。敬请期待！

作者简介 ：