05｜TDD中的測試（1）：狀態(tài)驗證為什么是主要的使用方式？
測試的基本結(jié)構(gòu)
需要說明一下的是，測試上下文（Test Context）在很多文獻中被稱作測試夾具（Test Fixture）。
夾具是個隱喻，是木工或者其他制造過程中，用以固定待加工工件的器具（上圖中，棕色部分看起來是不是“夾”住了待測系統(tǒng)）。當然，這種拿一個生僻概念來隱喻另一個生僻概念的操作，也是很迷了。我要不是因為做吉他學習了木工，也不明白為什么要叫 Fixture。拋開這個隱喻，直接稱作測試上下文其實就簡單易懂多了。
再多說一句，如果使用Fit系自動化測試工具（Fit、Fitness，甚至 concordion、selenium），F(xiàn)ixture 則表示驅(qū)動待測系統(tǒng)的交互接口，也叫 Driver。這也是為啥，Selenium 后來改叫 WebDriver 的原因。
言歸正傳，這四個階段的主要作用是：
初始化。主要是設(shè)置測試上下文，從而使待測系統(tǒng)（System Under Test）處于可測試的狀態(tài)。例如，對于需要操作數(shù)據(jù)庫的后臺系統(tǒng)，測試上下文包含了已經(jīng)灌注測試數(shù)據(jù)的測試用數(shù)據(jù)庫，并將其與待測系統(tǒng)連接。
執(zhí)行測試。就是按照測試腳本的描述與待測系統(tǒng)互動。例如，按照功能描述，通過 API 對系統(tǒng)進行相應(yīng)的操作。
驗證結(jié)果。就是驗證待測系統(tǒng)是否處于我們期待的狀態(tài)中。例如，經(jīng)過測試，數(shù)據(jù)庫中的業(yè)務(wù)數(shù)據(jù)是否發(fā)生了期待中的改變。
復原。就是將測試上下文、待測系統(tǒng)復原回測試之前的狀態(tài)，或者消除測試對于待測系統(tǒng)的副作用。例如，刪除測試數(shù)據(jù)中的數(shù)據(jù)（通常是通過事務(wù)回滾）。
測試上下文的設(shè)置將直接影響編寫測試的難度，以及維護測試的成本。
在測試的四個步驟中，驗證結(jié)果是最核心的一步，也是最核心的技術(shù)。驗證結(jié)果有兩種方式：狀態(tài)驗證（State Verification）和行為驗證（Behavior Verification）。
狀態(tài)驗證
狀態(tài)驗證是指在與待測系統(tǒng)交互后，通過比對測試上下文與待測系統(tǒng)的狀態(tài)變化，判斷待測系統(tǒng)是否滿足需求的驗證方式。
狀態(tài)驗證是一種黑盒驗證，它將測試上下文與待測系統(tǒng)當作一個整體。當待測系統(tǒng)不存在內(nèi)部狀態(tài)，而通過作用于依賴組件（Depended On Component）達成功能的時候，我們會從依賴組件中獲取狀態(tài)，以驗證待測系統(tǒng)。如下圖所示：
對于測試環(huán)境中存在進程外組件的情況，問題就要復雜一些了。在這種情況下，增量狀態(tài)驗證（Delta Verification）是一種有效的手段：
在這個例子里，在每一個測試復原時，都使用了“drop-and-create”來清除數(shù)據(jù)庫中的數(shù)據(jù)，從而消除狀態(tài)累積。但如果因為種種原因（比如測試數(shù)據(jù)量很大），使得每次清除測試數(shù)據(jù)都變得不現(xiàn)實時，就可以使用增量狀態(tài)驗證來降低狀態(tài)累積的影響。
