关于 ThoughtWorks Radar 4 的思考

ThoughtWorks 2024 Radar 已发布（您可以一键下载 PDF，无需烦人的注册）。以下是两件事：

1. 我讲述了我在组件测试中感到困惑的事情
2. 很酷的新工具，用于调查或找出他们从“评估”到“采用”的原因

如果您只是想了解一些很酷的新东西，请跳过我的组件测试咆哮。

组件测试：采用

我对这个“采用”有很多疑问。我现在的雇主投入了大量的培训和工具来帮助团队进行组件测试，这是我喜欢的。我不喜欢的是另一种测试技术，它的定义因谈论它的人而异。

让我按照我了解它们的时间顺序概述一下我在野外看到的几个定义，我认为_ThoughtWorks 的定义是最后一个：

• Storybook 帮助单独测试 React 组件，被组件框架作者大量使用
• 使用 Cypress 的组件测试在隔离的浏览器环境中测试组件
• 我对赛普拉斯白盒测试的最新定义，意味着所有外部 I/O 调用（fetch/xhr、加载 JSON、读取本地存储等）都是 cy.intercepted 或存根/模拟

这些都不一样。上述上下文中的组件是指 UI 组件，类似于 a 或 a，它由许多其他组件、代码和 CSS 组成。我说“有点”，因为在 Storybook 和 Cypress 中，你使用的是真正的浏览器，而不是像 JSDom 这样的假浏览器。在这种情况下，我相信使用真正的浏览器可以解决很多问题，特别是围绕验收测试，而不是单元测试。我的经历与他们所引用的相反：你可以使 Cypress/Playwright 变得非常快（使用像 it.only 之类的东西，大量存根，设计你的 UI 以更加解耦来测试特定的用户流），以及数量对于用户来说，我对应用程序的运行充满信心。考虑到 Elm 的类型系统，这是您验证 Elm 代码中是否存在竞争条件的主要方法，而且这很好，因为您可以花更多时间使用该技术编写验收测试。 Cypress 白盒测试并不脆弱；它们具有确定性，这就是我们都喜欢它们的原因。

但是，我确实承认调试可能具有挑战性。仅仅因为你“在浏览器中”并不总是能让你广泛地了解为什么某些东西会崩溃，尽管有断点、调试器关键字、编译的源代码、对网络调用的洞察以及各种日志都可供你使用（不是开玩笑） ，即使如此，你仍然可以说“伙计，为什么这不起作用……”）

接下来，ThoughtWorks 和 Cypress 都引用了“端到端”测试。这里的定义也很模糊。以下是我见过的一些定义：

• Dave Farley 的 e2e 方案，基本上是验证“所有事物”协同工作（不要与早期 All Up 测试的推动相混淆）
• 赛普拉斯的黑盒测试，您不会存根/模拟 ajax 调用和其他 I/O，这只是测试“您的站点及其集成”
• ThoughtWorks 似乎在说 Playwright/Cypress/Selenium 主要是 e2e 工具，我将它们视为验收测试工具，不包括 Cypress 组件测试功能，这与 Storybook 有点相似
• 希勒尔·韦恩也这么称呼他们

最后，我从来不喜欢 React 的组件测试扩展。它们充斥着大量的模拟/副作用，并强烈鼓励您使用 JQuery 技能来验证“我的组件正确渲染”，这并不总是等同于“正确工作”，感觉就像打破抽象，并测试 React 是否正确正在工作。相反，无论是 React、Angular 还是 Elm，我一直觉得测试你的代码是有效的，主要创建纯组件，并测试你在验收测试（Cypress 或 Playwright）中验证的“智能组件”（例如具有副作用的组件） .

JavaScript Web 开发人员有不同的观点和不同的单词定义。这通常很好，但作为一个将 ThoughtWorks 作为年轻成年英雄的人，不断推荐 Martin Fowler 和其他 ThoughtWorks 撰写的作品作为学习的精彩建议，并且活动希望有一天与他们合作......你可以明白为什么这种完全相反的观点是给我带来了信仰危机。

所以：

1. 同意以各种形式进行组件测试
2. 不同意 JSDom 并在您选择的单元测试语言中“断言我的组件的列表项 2 有一个粗体标记，内部文本为‘cow’”。

无论如何，以上内容在各种语言中都有细微差别。例如，Angular 和 Lit/WebComponents，如果您避免模板具有超出 if 的任何逻辑，并将绑定切换到公共组件变量，那么与 React 和其他公开的当前框架相比，单元测试和断言副作用会更容易。然而，Angular 和一些 WebComponent 框架需要冗长的设置代码，这些代码本身极难调试，而 React/Elm 则相反。

此外，我知道创建这些 PDF 是一项艰巨的工作，尝试总结技术方面的任何内容也是如此，所以我确信我只是缺少大量的上下文。

持续部署：采用

看到我的首席执行官在年度演讲中谈论这一点，真是太棒了。我知道尝试最小 CD 的活动对人们来说可能是一个巨大的改变，但这是我在工作中见过的最好的方式，很高兴看到它在采用中被明确地调用。

傀儡：评估

当 Zio 创建者参与创建这个名为 Golem 的不会崩溃的状态机即服务时，我感到非常兴奋。我更加兴奋，因为他们支持 Grain，一种 OCAML 风格的 FP 健全类型语言。我永远找不到时间/灵感去玩，因为我仍然感觉自己陷入了“一切都是 AWS”的漩涡中。是的，我在生产中使用过 CloudFlare，但是……作为 AWS Step Functions 的粉丝，这似乎是一个很酷的主意。其中一个周末我会再次尝试使用 TypeScript，因为 Grain 似乎不再是一种选择。

布鲁诺：采用

许多 REST 客户端（其中一些内置于 VSCode 中）正被各种公司阻止，因为它们在其服务器上托管您的内部 API 详细信息或将详细信息发布到其他地方。像 Postman 和 Insomnia 之类的东西已经开始要求订阅，尽管他们声称不需要，但这只会让事情变得更糟。因此，人们迫切需要寻找不共享数据的类似工具。 Bruno 是我需要检查的一个，因为我不再被允许使用 ThunderClient。

视觉回归测试工具：采用

CSS 可以通过多种方式破坏整个应用程序，并且无法轻松地进行单元测试或验收测试来防止这种情况发生。我真的很难使用早期的 React 快照工具，并且考虑到大量的误报，我觉得较小的网站没有投资回报率。 Applit 和 BackstopJS 等工具是众多工具中的一部分，包括服务，用于验证您的网站外观和工作是否正常。它们通常在管道中的验收测试之后或同时运行。我大约有 5 分钟使用 Applit 工具的经验，但绝对想看看 Backstop。

GitButler：评估

我最兴奋的是 GitButler。作为一个在经历了基于主干的开发后讨厌 Pull Requests 的人，并对围绕“抽象而不是 PR”的各种工具的状态和放弃感到失望，GitButler 看起来可以在切换到制作 PR 的 PR 的上下文中恢复我的理智。

米斯：评估

Mise 有点奇怪，因为我从来没有遇到过使用 nvm 管理 Node.js 版本和使用 pipelinev 管理/运行 Python 项目的问题，所以很好奇，可以尝试一下，看看有什么大惊小怪的。

模拟：评估

我讨厌嘲笑。我倾向于使用允许副作用的语言，并且与不遵循 Pure Core、Imperative Shell 的开发人员一起工作。因此，我能做的任何事情来更多地了解我的敌人以及如何管理它，都是对时间的一种很好的利用，Mockoon 是另一位模拟创建者。

Rspack：评估

值得庆幸的是，我从来不需要与 Webpack 集成。不幸的是，我多次受到_其他人_与 Webpack 集成的影响。 Vite 是呼吸新鲜空气的地方；超级快，而且成功了。因此，听到另一个速度竞争者是很有趣的。 Vite 获胜不仅是因为其惊人的速度，还因为出色的开发者体验，太酷了，看看 Rspack 会发生什么。

泽德：评估

尽管 VSCode 对我来说很重要，但我很高兴尝试 Zed IDE，因为内置结对编程、超快的速度，而且因为 Roc lang 创建者加入了他们的团队。

PKL：试用

我第一次转向 Pkl 是在我的 Dhall 幻灭低谷阶段（Dhall 很酷，但男人太难了），是 James Ward 带来的。它看起来是一种具有足够类型的语言，可以更安全地编译 YAML/JSON 配置文件。我已经有足够多的 YAML/JSON 错误配置破坏了生产，所以我开始寻找编译这些问题的方法，Dhall 提供了很多帮助，但是学习曲线和编译器错误很难解决，而且我从未在同行中感到兴奋。希望 Pkl 能够在这里取得进展。

结论

请务必自己下载 PDF，因为我忽略了其中的大量新技术和现有技术（法学硕士、基础设施、数据科学），我觉得这些技术很无聊，但其他人可能会觉得引人注目。

以上是关于 ThoughtWorks Radar 4 的思考的详细内容。更多信息请关注PHP中文网其他相关文章！