關於 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中文網其他相關文章！