Agile Principles, Patterns, and Practices in C# 無瑕的程式碼 敏捷完整篇 第4章 測試

        第四章測試可與《Clean Code》第九章單元測試對照看，本章內容作者有寫一個C#版本簡單測試範例，更詳盡說明測試驅動開發的好處。

撰寫單元測試是在進行驗證、設計、撰寫說明文件。

測試驅動開發

我對那三句話有反感！翻譯成這樣不會有人看得懂。反正測試驅動開發就是先寫測試程式，再寫原本要寫的產品程式。

有測試程式就可以放心對原始程式進行修改，不怕把程式改壞。

寫測試程式可以用不同的角度看問題，我們可以設計出便於呼叫的軟體。

程式要可測試就必須與周遭解耦合，測試會迫使我們去除軟體的耦合。

測試程式就像範例程式，也是程式的說明文件。

先寫測試的例子

Listing4-1是一個測試程式範例，作者先寫測試程式，表現出自己的意圖。

測試程式告訴我們程式如何工作，可以根據測試程式寫出已經命名的方法。測試程式充當了說明文件。

測試促使模組之間隔離

圖4-1是原始的應用模式，假設這張圖只畫在白板上，現在要先撰寫測試程式。

要替Payroll寫測試程式的時候就會發現問題。

要使用何種資料庫？資料格式？如何溝通？如何驗證？

參考圖4-2，作者採用MOCK OBJECT (?) 解決問題，在Payroll 類別與協作者之間插入介面，建立這些介面的測試替身。

Listing4-2 測試程式展示了測試意圖。

意外獲得的解耦

從測試程式可看出寫完測試程式也完成解耦合，寫測試程式可改善設計。

驗收測試

單元測試只是整體測試一部分，單元測試只有測試小單元，沒有測試系統整體的正確性。

單元測試是用來驗證小單元的白盒測試。驗收測試用來驗證系統滿足客戶需求的黑盒測試。

「黑盒」代表只知道輸入與輸出，不知到內部如何運作。

驗收測試由不了解系統內部機制的人撰寫，驗收測試是真正的需求文件。驗收測試必須能夠自動執行。

為了使系統具備可測試性，必須要在高的系統架構層面對系統進行解耦。例如為了不透過UI能夠存取業務規則，就會解除UI與業務規則的耦合。

作者使用FitNesse工具撰寫驗收程式。必須寫出API函式才能讓FitNesse工具進行驗收測試。

意外獲得的架構

先考慮驗收測試引領我們思考API函式的概念，可獲得良好的架構。

總結

驗證是撰寫測試的好處之一。

測試程式是產品程式的說明文件。

單元測試使用程式語言撰寫，為了讓客戶能夠閱讀驗收測試，驗收測試使用簡單的表格式語言撰寫。

測試可優化程式架構和設計，可以幫助程式解耦合，對軟體結構有正面影響。