在過去幾年，服務導向架構已轉向規模較小、更專注的「微」服務。這種方法有許多好處，例如能夠獨立部署、擴充和維護每個元件，以及讓多個團隊並行開發。然而，一旦引入這些額外的網路分割，就需要重新考量適用於單一處理程序應用程式的測試策略。在此，我們計畫討論多種方法，用於管理多個獨立部署元件的額外測試複雜性，以及如何讓測試和應用程式保持正確，儘管有多個團隊各自擔任不同服務的守護者。

「測試金字塔」是一個比喻，告訴我們將軟體測試分組到不同粒度的層級中。它也提供一個概念，說明我們應該在每個群組中擁有多少測試。儘管測試金字塔的概念已經存在一段時間，但團隊仍然難以將其適當地付諸實踐。本文重新探討測試金字塔的原始概念，並說明如何將其付諸實踐。它說明您應該在金字塔的不同層級中尋找哪些類型的測試，並提供如何實作這些測試的實務範例。

Ruby on Rails 的創建者 David Heinemeier Hansson 在 RailsConf 發表主題演講，宣稱 TDD 已死。這在 Rails 和更廣泛的軟體開發社群中引發了預料中的大量爭議。這也導致了 David、Kent 和我之間一些有趣的對話。我們認為這些對話足夠有趣，其他人可能也想觀看，因此錄製了一系列影片聚會，討論 TDD 在軟體開發中的角色。

我們軟體系統中的可觀察性一直很有價值，在雲端和微服務的時代變得更加重要。然而，我們新增到系統中的可觀察性往往相當低階且技術性，而且似乎太常需要用各種記錄、儀器和分析架構的粗糙、冗長呼叫來充斥我們的程式碼庫。本文描述了一個模式，可以清理這個混亂，並允許我們以一種乾淨、可測試的方式新增與業務相關的可觀察性。

2014 年初發現了兩個電腦安全漏洞：Apple 的「goto fail」漏洞和 OpenSSL 的「Heartbleed」漏洞。兩者都有可能造成廣泛且嚴重的安全失敗，其全部範圍我們可能永遠不知道。鑑於其嚴重性，軟體開發專業人員有必要反思如何才能偵測到它們，以便我們提高未來預防這些類型的缺陷的能力。本文探討單元測試可以扮演的角色，說明單元測試，更重要的是單元測試文化，如何找出這些特定錯誤。它繼續探討這種文化的成本和好處，並描述這種文化如何在 Google 中灌輸。

自動化回歸套件可以在軟體專案中發揮至關重要的作用，既有助於減少生產中的缺陷，又對於演化設計至關重要。在與開發團隊交談時，我經常聽說非決定性測試的問題 - 有時通過，有時失敗的測試。如果不加以控制，非決定性測試會完全破壞自動化回歸套件的價值。在本文中，我概述了如何處理非決定性測試。最初隔離有助於減少它們對其他測試的損害，但你仍然必須儘快修復它們。因此，我討論了非決定性的常見原因的處理方法：缺乏隔離、非同步行為、遠端服務、時間和資源洩漏。

您是否曾參加過「展示」，開發人員自豪地展示他們 API 的 JSON 輸出畫面，而使用者卻感到困惑和分心，無法理解任何內容？您是否曾嘗試在開發中使用 API，並對難以找到正確的 JSON 酬載和標頭咒語感到沮喪，無法測試功能？展示前端是一個簡單的 UI，提供基本功能來展示和探索此類 API。

LLM 工程不僅涉及提示設計或提示工程。在本文中，我們將分享一系列工程實務，這些實務幫助我們在最近的專案中快速且可靠地交付 LLM 應用程式原型。我們將分享 LLM 應用程式的自動化測試和對抗性測試、重構，以及 LLM 應用程式架構和負責任 AI 的考量。

「模擬物件」一詞已成為一個流行的詞彙，用來描述模擬真實物件以進行測試的特殊案例物件。現在，大多數語言環境都有讓建立模擬物件變得容易的架構。然而，人們常常沒有意識到，模擬物件只是特殊案例測試物件的一種形式，它能支援不同的測試樣式。在本文中，我將說明模擬物件如何運作，它們如何鼓勵基於行為驗證的測試，以及它們周圍的社群如何使用它們來開發不同的測試樣式。

JavaScript 社群似乎有一個常見的誤解，認為測試非同步程式碼需要與測試「常規」同步程式碼不同的方法。在本文中，我將說明為什麼通常並非如此。我將強調測試支援非同步行為的程式碼單元與本質上非同步的程式碼之間的差異。我也將展示基於承諾的非同步程式碼如何適用於乾淨且簡潔的單元測試，這些測試可以用清晰、可讀的方式進行測試，同時仍驗證非同步行為。

我們提供一小時的持續交付概觀。主題包括持續交付的理由、部署管線、持續整合、DevOps 和部署策略。重點是 Jez 將候選版本擬人化為希臘神話中的英雄。

現代化模擬工具對我們處理舊有程式碼的能力可能產生的正面影響，以及使用這些工具的潛在負面影響。

傳統上，QA 專注於在軟體發布到生產環境之前進行測試，以查看它是否已準備好進行此類發布。但現代化 QA 組織也越來越關注在生產環境中執行的軟體。透過分析日誌和其他監控工具，他們找出品質問題，並強調給開發組織。此方法特別適用於使用持續交付將新版本的軟體快速且可靠地投入生產環境的組織。

測試影響分析 (TIA) 是加速建置測試自動化階段的現代化方法。它的運作方式是分析原始碼的呼叫圖形，找出在變更生產程式碼後應執行哪些測試。Microsoft 已針對此方法進行廣泛的研究，但開發團隊也可以相當低成本地實作一些有用的東西。

我的同事 Joe Walnes 指出 我們的同事 Chris Stevenson 開發的令人著迷的簡單工具。TextDox（AgileDox 的一部分）是一個從 JUnit 測試案例自動產生文件檔的工具。聽起來很荒謬，但這就是 Wardish 的想法。

這是朋友的朋友告訴我的故事。我確定這一定是真的，至少在某個地方是真的。

如果您需要在程式碼中取得目前的日期或時間，請勿直接存取系統常式來取得該資料。請在常式周圍放置某種包裝器，讓您可以透過將「目前日期/時間」設定為特定值來覆寫它。這對於簡化測試非常重要。

以下是我最近發現的一個有趣的對比。兩個規模相似的企業應用程式專案（約 100 KLOC），環境類似（Java 和 .NET）。一個可以在一小時內完成完整的建置和測試，另一個則需要 2-3 分鐘。

（以下是您字典的補充內容。）

令人厭惡的（形容詞）：無法測試的軟體。

前幾天我在處理我的一些範例程式碼。我做了一些變更，讓所有東西都正常運作，執行測試，並將其提交到我的個人儲存庫。然後我轉到另一個區域並做了一些變更，結果前一個區域中有一些意外的測試中斷。現在執行自動化測試的一部分目的是找出意外的中斷，但這段範例程式碼有完全獨立的區域。這很奇怪。

探索性測試是一種測試風格，強調快速循環的學習、測試設計和測試執行。探索性測試並非嘗試驗證軟體是否符合預先寫好的測試腳本，而是探索軟體的特徵，提出發現，然後將其分類為合理行為或失敗。

Given-When-Then 是一種表示測試的風格，或者它的支持者會說，使用 SpecificationByExample 指定系統的行為。這是 Daniel Terhorst-North 和 Chris Matts 作為 行為驅動開發 (BDD) 的一部分而開發的方法。它作為許多測試架構（例如 Cucumber）的結構化方法出現。您也可以將其視為 四階段測試 模式的重新表述。

某些程式元素本質上難以測試，甚至無法測試。這些元素中的任何邏輯因此容易出現錯誤，且難以演進。為了減輕此問題，請將盡可能多的邏輯移出難以測試的元素，並移至程式碼庫中其他更友善的部分。透過讓不可測試的物件變得謙遜，我們可以減少它們藏有惡意錯誤的機率。

記憶體中資料庫是一種完全在主記憶體中執行的資料庫，不會觸及磁碟。它們通常以嵌入式資料庫的形式執行：在流程啟動時建立，嵌入在該流程中執行，並在流程結束時銷毀。

我經常收到有關 JUnit 測試架構中設計選擇之一的問題，即為每個測試方法執行建立新物件的決定。足夠保證快速建立 bliki 條目。（然而，我幾乎不得不指出，我撰寫有關 JUnit 的文章並不表示我不認為其他形式的測試很重要。有許多有用的測試活動，儘管 JUnit 及其相關技術對許多活動而言很有價值，但它並非萬靈丹。對於更多有關測試的部落格文章，我建議您查看 Brett Pettichord、Brian Marick 和 James Bach 的部落格。您也不應假設我撰寫有關 xUnit 測試的文章暗示重構、使用案例或使用牙線不重要。）

在使用傳統系統時，找出並建立接縫很有價值：我們可以在其中變更系統的行為，而無需編輯原始碼。一旦找到接縫，我們就可以使用它來中斷相依性以簡化測試，插入探針以提高可觀察性，並將程式流程重新導向到新模組，作為傳統置換的一部分。

測試增強設計中常見的問題是，如何在測試模式中建立服務 Stub，同時讓實際服務在生產環境（以及某些測試）中存在。我的幾位同事分享了他們的點子。

最近我花了一些時間參與我個人最喜愛的 Thoughtworks 專案之一。這個專案始於 1998 年，當時使用的是新的 J2EE 技術。多年來，它經歷了一段引人入勝的歷史：從 EJB 開始，將它們移除，外包到班加羅爾，再回到芝加哥。許多人進出過這個專案，專案的人數在 6 到 60 人之間變化。總體而言，這個專案投入了超過 300 個員工年的工作量，規模約為 100 KLOC。

物件母體是一種在測試中使用的類別，用於協助建立範例物件，供您用於測試。

當您針對網頁撰寫測試時，您需要參照該網頁中的元素，才能按一下連結並判斷顯示的內容。但是，如果您撰寫的測試直接操作 HTML 元素，則您的測試會容易受到 UI 變更的影響。頁面物件會以特定於應用程式的 API 封裝 HTML 頁面或片段，讓您可以在不深入研究 HTML 的情況下操作頁面元素。

使用 TestDouble 的經典案例之一是呼叫遠端服務時。遠端服務通常很慢，而且經常不可靠，因此使用雙物件是讓您的測試更快且更穩定的好方法。

自我測試程式碼是我在 重構 中用來指稱與功能性軟體結合撰寫全面自動化測試的做法。如果執行得當，這會讓您能夠呼叫執行測試的單一指令，而且您有信心這些測試會找出隱藏在程式碼中的任何錯誤。

2002 年，我在 XP/Agile Universe 參加研討會時，注意到「範例規範」這個詞組，它可以描述 XP 中測試所扮演的角色之一。

當我聽我們的開發團隊討論他們的工作時，一個常見的主題是他們不喜歡靜態變數中保存的內容。我們通常會看到常見的服務或元件保存在具有靜態初始化項目的靜態變數中。靜態變數（在多數語言中）最大的問題之一是您無法使用多型來以一個實作替換另一個實作。這對我們來說很麻煩，因為我們是測試的忠實愛好者，而要進行完善的測試，能夠以 服務 Stub 替換服務非常重要。

合成監控（也稱為語意監控）會定期對應用程式的自動化測試子集執行測試，以針對實際生產系統進行測試。結果會推送到監控服務中，在發生故障時觸發警示。此技術結合了自動化測試和監控，以偵測生產環境中失敗的商業需求。

隨著我的職業生涯轉向全職撰寫，我常常擔心自己會遠離日常軟體開發的現實。我已經看過其他知名人物失去與現實的聯繫，我害怕自己也會步上後塵。我對此最大的抵抗來源是 Thoughtworks，它就像一劑規律的現實良藥，讓我腳踏實地。

Thoughtworks 也扮演著從現場汲取靈感的來源，而我樂於撰寫同事們發現和開發的有用事物。通常這些都是有用的點子，我希望我的一些讀者能夠使用。我今天的題目並不是那麼令人愉快的題目。這是一個問題，而且我們沒有答案。

時不時我會聽到有人詢問他們應該追求什麼價值的測試涵蓋範圍（也稱為程式碼涵蓋範圍），或自豪地說明他們的涵蓋範圍層級。此類聲明都錯失重點。測試涵蓋範圍是找出程式碼庫中未測試部分的有用工具。測試涵蓋範圍作為一個數值聲明來說，對於你的測試有多好幾乎沒有用處。

Gerard Meszaros 正在撰寫一本書，目的是捕捉使用各種Xunit 架構的模式。他遇到的其中一件尷尬的事情，就是替身、模擬、偽造、傀儡和其他供人們在測試中替換系統部分所使用的東西有各種不同的名稱。為了處理這個問題，他想出了自己的詞彙，而我認為這值得進一步傳播。

測試驅動開發 (TDD) 是一種透過撰寫測試來引導軟體開發的軟體建置技術。它是由Kent Beck 在 1990 年代後期開發，作為極限編程的一部分。基本上，我們重複執行三個簡單步驟

契約設計 (DbC) 和測試驅動開發 (TDD) 的倡導者之間一直存在一場長期的低調爭論。我現在不會深入探討，但當我與Daniel Jackson 交談時，我會傳達一個將兩者合併的想法。

測試金字塔是一種思考方式，說明應如何使用不同類型的自動化測試來建立平衡的投資組合。其重點在於，你應該執行比透過 GUI 執行的廣泛堆疊測試 多得多的低階單元測試。

我目前正在 XP 日 的一個會議中，Owen Rogers 和 Rob Styles 正在討論 XP 的單元測試和驗收測試之間的差異。這讓我想起一個問題 - 用於撰寫驗收測試的語言應該是什麼？

我正在翻閱一些舊筆記，並發現 Rich Garzaniti 給我的簡單但有用的提示。

XUnit 是給予許多在軟體開發人員之間廣為人知的測試架構的家族名稱。這個名稱是從 JUnit 衍生而來的，而 JUnit 是這些測試架構中最早廣為人知的。