xUnit 測試模式

如果你前往 junit.org，你會看到我的一句話：「在軟體開發領域中，從未有這麼多人，如此依賴這麼少程式碼」。JUnit 被批評為小事一樁，任何合理的程式設計師都能在週末完成。這句話沒錯，但完全錯失重點。JUnit 如此重要的原因，以及它值得邱吉爾式的讚譽，在於這個小工具的存在，對許多程式設計師來說，是一項根本性的轉變。測試已轉變為程式設計中首要且核心的部分。過去也有人提倡，但 JUnit 比任何其他工具更能實現它。

當然，這不只是 JUnit 的功勞。JUnit 已被移植到許多程式語言中。這個鬆散的工具家族，通常稱為 xUnit 工具，已遠遠超出了 Java 的根源。（當然，它的根源並非真正來自 Java，因為肯特·貝克早在幾年前就為 Smalltalk 編寫了這段程式碼。）

xUnit 工具，更重要的是它的哲學，為程式設計團隊提供了絕佳的機會。一個機會，可以撰寫強大的回歸測試套件，讓團隊能夠大幅變更程式碼庫，風險卻低得多。機會，可以透過測試驅動開發重新思考設計流程。

但是，這些機會也帶來新的問題和新技術。與任何工具一樣，xUnit 家族可以善用或濫用。有想法的人已經找出各種使用 xUnit 的方法，以有效組織測試和資料。就像物件導向的早期一樣，真正使用這些工具的許多知識都隱藏在熟練使用者的腦海中。沒有這些隱藏的知識，你無法真正獲得全部的好處。

大約二十年前，物件導向社群的人們意識到物件的這個問題，並開始制定答案。這個答案是，以模式的形式描述他們的隱藏知識。傑瑞德·梅薩羅斯是這樣做的先驅之一。當我第一次開始探索模式時，傑瑞德是我學習的領導者之一。與模式世界中的許多人一樣，傑瑞德也是極限編程的早期採用者，因此從最早的時候就開始使用 xUnit 工具。因此，他理應承擔起以模式形式擷取專家知識的任務。

自從第一次聽聞這個專案後，我就對它感到興奮不已。（我必須發動突擊隊突襲，從 Bob Martin 那裡偷走這本書，因為我希望能讓它出現在我的系列中。）就像任何一本好的模式書籍，它為該領域的新手提供知識，同樣重要的是，它為經驗豐富的從業人員提供詞彙和基礎，以便他們將知識傳授給同事。對許多人來說，著名的四人幫書籍解鎖了物件導向設計的隱藏寶藏，而這本書對 xUnit 來說也發揮了相同的作用。