範例規格

2002 年，我參加了 XP/Agile Universe 的工作坊，當時「範例規格」這個詞句讓我印象深刻，認為可以描述測試在 XP 中的角色之一。

（現在談論測試驅動開發 (TDD) 與測試有關，非常不合時宜，但就像 Jon 一樣，我認為擁有全面的自動化測試套件比「副作用」一詞所暗示的更有價值。就像有人提供我一百萬美元，讓我爬上山一樣。我可能會說，爬山的目的主要是享受大自然，但對我的錢包來說，副作用絕不微不足道...）

範例規格並非我們大多數人過去認為的規格。規格應該是通用的，涵蓋所有情況。範例只強調幾個重點，您必須自己推論出概括。這表示範例規格無法成為您使用的唯一需求技術，但並不表示它無法扮演領導角色。

到目前為止，對於嚴格規範的主流概念，也就是那些可以清楚判斷通過或失敗的概念，是使用前置條件和後置條件。這些技術在形式化方法中佔據主導地位，也支撐著契約設計。這些技術有其適用的場合，但並非理想。在某些情況下，前置條件和後置條件可能非常容易撰寫，但在其他情況下則可能非常棘手。我曾嘗試在許多企業應用程式設定中使用它們，我發現，在許多情況下，撰寫前置條件和後置條件與撰寫解決方案一樣困難。範例規格的一大優點是，範例通常更容易想出來，特別是對於我們為之撰寫軟體的非技術人員來說。（提摩西·巴德指出，雖然你可以透過前置條件和後置條件顯示許多堆疊行為，但撰寫顯示 LIFO 屬性的前置條件和後置條件非常棘手。）

TDD 測試的一項重要屬性是它們涉及雙重檢查。事實上，這突顯了 XP 社群的一個有趣小謊言。他們非常強調「只說一次」這件事，但事實上，他們總是說兩次：一次在程式碼中，一次在測試中。Kent 指出，這個雙重檢查原則是一項重要的原則，而且人類肯定一直都在使用它。雙重檢查的價值在很大程度上與對雙重檢查的每一面使用不同的方法有關。將範例規格與生產程式碼結合使用表示你以截然不同的方式表達兩件事，這會增加它們找出錯誤的能力。

形式化規格社群一直難以驗證設計是否符合規格，特別是在不使用容易出錯的人類的情況下執行此操作。對於範例規格來說，這很容易。這是範例規格在理論上價值較低但在實務上價值較高的另一個案例。

一位契約設計愛好者指出，如果你以測試的形式撰寫規格，則供應商可以透過僅對特定測試輸入傳回硬編碼回應來滿足規格。我對此的輕率回答是，如果你擔心這個問題，那麼測試與契約設計之間的問題是你最不需要擔心的。但這裡有一個嚴肅的問題。測試永遠無法完整，因此它們必須始終由其他機制備份。由於我是一個扭曲的心靈，我實際上認為這是一個優點。由於顯然範例規格還不夠，因此顯然你需要採取更多措施來確保一切都能正確傳達。傳統需求規格最危險的事情之一是，當人們認為一旦他們寫完它，他們就完成了溝通。

範例規格僅適用於雙方合作而非對抗的工作關係脈絡中。範例會觸發設計團隊中的抽象，同時讓抽象保持基礎。您確實需要更多東西，例如定期對話、領域驅動設計等技術，甚至還有契約設計的劑量。儘管我從未有機會充分使用契約設計（例如使用 Eiffel），但我會定期以契約條款思考介面。範例規格是一個強大的工具，也許是我最常使用的工具，但絕不是我唯一的工具。

（若要進一步思考範例規格，即使不是以該名稱，請參閱Brian Marick的文章。在他的網站上某處可能有一個超級頁面總結了他的觀點。當然，找到它不如在您嘗試時閱讀那裡的所有內容有價值）

一些後續評論

在我第一次撰寫本文幾年後，Cedric Beust 發表了一篇文章批評敏捷方法，這引起了一場小型的部落格爭吵。 Jeff Langr 和 Bob Martin 提出反駁，而我再次透過饋送發布這篇文章。Jeff Langr 後來增加了一個不錯的範例，使用測試作為 Java 的 Math.pow 函數的範例規格。

於 2011 年 11 月 17 日重新發布