目錄
- PART I: 入門
- Chap 1: 單元測試基礎
- Chap 2: 第一個單元測試
- PART II: 核心技術
- Chap 3: 透過虛設常式解決依賴問題
- Chap 4: 使用模擬物件驗證互動
- Chap 5: 隔離（模擬）框架
- Chap 6: 深入了解隔離框架
- PART III: 測試程式碼
- Chap 7: 測試階層和組織
- Chap 8: 好的單元測試的支柱
- Chap 9: 在組織中導入單元測試
- Chap 10: 遺留程式碼
- Chap 11: 設計與可測試性
前言
先分享一下到目前為止的心得與感想，我原本對於對於單元測試的了解程度：確實有在公司專案中實作過，但基於時間總是緊湊並沒有累積足夠的經驗，也說真的不知到底對不對、又好不好。
總體來說，原本的我對於單元測試的理解：一知半解。
那目前看完前面兩個章節，我感受到自己已經有了質的飛躍！（飄～）主要針對思維跟細節的部分，旁敲側擊的思考，觸發不同角度的靈感。
閒話家常，風塵僕僕，我們要進入重點章節了！接下來，我們來聊聊「虛設常式（stub）」，走起～
P.S. 這章節真的很長、很難，但也非常充實，我寫完之後重複看了十次以上，每次都有不同收穫，有些事慢慢就會懂了。
一、虛設常式簡介
在前一章，我們撰寫了第一個單元測試，並嘗試了幾個特性。這一章節，我們將討論更接近實務的例子。例如：測試的物件依賴於另外一個你無法控制（或尚未實作）的物件，可能是 Web 服務、系統時間、執行緒等等。關鍵點在於，你無法決定相依物件的 回傳值 ，虛設常式就派上用場了。老樣子，先來定義虛設常式。
虛設常式的定義：「虛設常式（stub）是在系統中產生一個可控的 替代物件，來取代一個外部相依物件（或協作者）。」
你可以在測試程式中，透過虛設常式來避免必須直接相依物件所造成的問題。
在詳談之前，先前提概要，下一個章節會再展開討論 虛設常式（stub）、模擬物件（mock） 以及 假物件（fake），它們很像，又有很重要的不同處，所以先在你心中埋顆種子，現在你只需要知道模擬物件跟虛設常式相當類似，但你會對模擬物件進行驗證，不會對虛設常式進行驗證。
二、找到 LogAn 中對檔案系統的依賴
在 LogAnalyzer 類別中，可以針對多種 log 檔案的副檔名，來設定特定的轉接器（adapter）進行處理。我們假設系統所支援的日誌檔案格式設定，是被存放在硬碟中的某個地方，IsValidLogFileName 的方法內容如下：
public bool IsValidLogFileName(string filename)
{
// 讀取設定檔案
// 如果支援該副檔名，回傳 true
}
那這個 method 有什麼問題呢？你的方法直接依賴於檔案系統。這種設計將使得被測試的物件無法進行單元測試，只能透過整合測試來驗證。
這就是 抑制測試（test-inhibiting） 設計的本質：當程式碼依賴於某個外部資源，即使程式碼邏輯完全正確，這種依賴仍可能導致測試失敗。
如何讓測試 LogAnalyzer 更簡單？
有句話是這麼說的：「任何物件導向的問題，都可以透過增加一層中介層來解決。」但若中介層過多又會是另一個問題，可能會讓邏輯過於複雜，這邊先不繼續討論。
現在如果要測試 LogAnalyzer 類別，唯一的方式是先在檔案系統中建立一個設定檔，但你試圖避免直接依賴於檔案系統，希望能讓單元測試更獨立些，而不是透過整合測試來確認。那接下來我們來談談怎麼解除依賴。
解除依賴的具體模式：
- 找到被測試物件所使用的介面或 API。
在太空人的例子中，這個介面就是太空梭模擬器裡的控制台與螢幕。 - 把這個介面的底層實作替換成你能模擬掌控的東西。
將太空梭模擬器裡各種螢幕、控制台、按鈕都連接到控制室。在控制室裡，測試工程師可以控制太空梭所有介面顯示的內容，以便測試太空人是否能正常作業。
將這樣的模式實作，需要更多的步驟：
- 找到導致被測試的工作單元無法順利測試的介面。
（在 LogAn 專案中，指的就是檔案系統中的設定檔。） - 如果被測試的工作單元是直接相依於這個介面，可以透過在程式碼中加入中介層，來隱藏這個相依的行為。
（在 LogAn 我們會加入一個中介層，其中一個方式是將直接讀取檔案系統的行為，移到一個單獨的類別中（FileExtensionManager）。） - 將這個相依介面的底層實作內容替換成你可以控制的程式碼。
（在 LogAn 我們將被測試方法所呼叫的執行個體（FileExtensionManager），替換成另一個虛設常式的類別（StubExtensionManager）。）
接著，來看這樣的想法怎麼透過重構（refactoring）來調整程式碼，並在設計中加入接縫（seam）的概念。
三、重構設計以提升程式碼的可測性
是時候介紹這本書中常會提到的兩個術語了：重構（refactoring）、接縫（seam）。
重構的定義：「重構是在不改變程式碼功能的前提下，修改程式碼的動作。也就是說，程式碼在修改前後的工作是一致的，不多也不少，只是程式碼看起來跟原本不一樣了。常見的重構：重新命名一個方法，或是把一個較長的方法內容拆成幾個較短的方法。」
- 提醒：如果沒有任何一種自動測試保護下，就冒然重構，可能會造成你的職涯提早結束。
接縫的定義：「接縫是指在程式碼中可以抽換不同功能的方法，這些功能例如：使用虛設常式類別、增加一個建構函式（constructor）參數、增加一個可設定的公開屬性、把一個方法改成可供覆寫的虛擬方法，或是把一個委派拉出來變成一個參數或屬性，供類別外部來決定內容。接縫透過實作開放封閉原則（Open-Closed Principle）來完成，類別的功能開放擴充彈性，但不允許直接修改該功能內實作的原始程式碼（類別功能對擴充開啟，對直接修改封閉）。遵循開放封閉原則，設計的程式碼就會有接縫。」
你可以在重構程式碼過程中，透過加入一個新接縫，既可調整原本程式碼的設計，同時又可以維持原有的功能不被改變，這就是為什麼前面新增了 IExtensionManager 的介面。
在測試中要解除依賴，可以在程式碼加入一個或多個接縫，只要能確保重構後程式碼所提供的功能與重構前完全一樣。
解除依賴有兩種重構方式，其中後者相依於前者：
- A 型：將具象類別（concrete class）抽象成介面（interfaces）或委派（delegates）。
- (α1) 擷取介面以替換底層實作內容
- B 型：重構程式碼，以便將委派介面的偽實作注入目標物件中。
- (β1) 在被測試類別中注入一個虛設常式的實作內容
- (β2) 在建構函式注入一個假物件
- (β3) 從屬性的讀取或設定中注入一個假物件
- (β4) 在方法被呼叫前注入一個假物件
接下來將逐一說明。
(α1) 擷取介面以便替換底層實作內容
α1.1: 擷取出讀取檔案系統的類別，並呼叫它的方法
public bool IsValidLogFileName(string fileName)
{
FileExtensionManager mgr = new FileExtensionManager();
return mgr.IsValid(fileName); // 使用被擷取出來的類別
}
class FileExtensionManager
{
public bool IsValid(string fileName)
{
// 在這裡讀取檔案
}
}
接著，可以增加一個「某種形式的 ExtensionManager」取代具體的 FileExtensionManager，可以透過一個基底類別或介面讓 FileExtensionManager 繼承或實作。
接下來，我們來調整一下程式碼，透過一個新介面來讓程式碼更容易測試。
α1.2: 從一個已知的類別擷取出介面
public class FileExtensionManager: IExtensionManager // 實作這個介面
{
public bool IsValid(string fileName)
{
...
}
}
public interface IExtensionManager // 定義這個新介面
{
bool IsValid(string fileName);
}
public bool IsValidLogFileName(string fileName)
{
IExtension mgr = new FileExtensionManager(); // 定義這個介面型別的變數
return mgr.IsValid(fileName);
}
以上程式碼，你建立一個介面 IExtensionManager ，上面有個 IsValid(string) 的方法，並讓 FileExtensionManager 實作這個介面。
程式碼的功能沒有改變，但現在已經可以在測試程式裡面，用一個自己建立的「假的」manager 來取代原本「真的」 FileExtensionManager 以便獨立測試。
你還沒建立這個虛設常式的 ExtensionManager，下一步，我們來建一個吧！
(β1) 在被測試類別中注入一個虛設常式的實作內容
β1.1: 一個總是回傳 true 的簡單虛設常式程式碼
public class AlwaysValidFakeExtensionManager: IExtensionManager // 實作 IExtensionManager 介面
{
pubic bool IsValid(string fileName)
{
return true;
}
}
首先，留意這個類別的命名，這個類別不叫 StubExtensionManager 或 MockExtensionManager，而是 FakeExtensionManager，Fake 這個字眼，說明這個類別物件類似另一個物件，但它可能被當作「模擬物件（mock）」或「虛設常式（stub）」。（下一章會說明什麼是模擬物件）
透過 Fake 的命名，你就可以延遲決定，應該拿來當作模擬物件或虛設常式。
現在你有了一個介面，以及兩個實作此介面的類別，但目前被測試的方法還是呼叫具象類別：
public bool IsValidLogFileName(string fileName)
{
IExtension mgr = new FileExtensionManager(); // 定義這個介面型別的變數
return mgr.IsValid(fileName);
}
接著，我們得想辦法讓被測試的方法能去呼叫假物件，而不是直接使用 IExtensionManager 原本的實作內容。因此，需要再程式碼的設計中加入一個 接縫，以便注入虛設常式進行模擬。
依賴注入：在被測試單元中注入一個假的實作內容
在好幾種可行的方式，讓你可以建立基於介面的接縫，這些接縫讓你可以在類別中注入實作這個介面的物件，讓原本與類別的互動，改使用介面的方法。
幾個注意的方式：
- 在建構函式中得到一個介面的物件，並將其存到欄位（field）中供後續使用。
- 在屬性 get 或 set 方法中得到一個介面的物件，並將其存到欄位中供後續使用。
- 透過下列其中一種方式，在被測試方法呼叫前獲得一個介面的假物件：
- 方法的參數（參數注入）
- 工廠類別
- 區域工廠方法（local factory method）
- 前面幾種方式的變形
參數注入的方式相當簡單：給方法增加一個參數，就可以在呼叫這個方法時，傳入一個依賴物件進去。
接下來，將逐一介紹其他的依賴注入方式。
(β2) 從建構函式注入一個假物件（建構函式注入）
透過建構函式注入的過程
β2.1: 使用建構函式注入你的虛設常式
public class LogAnalyzer // 定義產品程式碼
{
private IExtensionManager manager;
public LogAnalyzer(IExtensionManager mgr) // 定義可被測試程式使用的建構函式
{
manager = mgr
}
public bool IsValidLogFileName(string fileName)
{
return manager.IsValid(fileName);
}
}
public interface IExtensionManager
{
bool IsValid(string fileName);
}
[TestFixture]
public class LogAnalyzerTests // 定義測試程式
{
[Test]
public void IsValidFileName_NameSupportedExtension_ReturnsTrue()
{
FakeExtensionManager myFakeManager = new FakeExtensionManager(); // 準備一個回傳 true 的虛設常式物件
myFakeManager.WillBeValid = true;
LogAnalyzer log = new LogAnalyzer(myFakeManager); // 傳入虛設常式物件
bool result = log.IsValidLogFileName("short.ext");
Assert.True(result);
}
}
internal class FakeExtensionManager: IExtensionManager // 建立一個最簡單的虛設常式內容
{
public bool WillBeValid = false;
public bool IsValid(string fileName)
{
return WillBeValid;
}
}
你應該可以看到以上的假物件，和之前看到的不一樣，之前是類似這樣：
public class AlwaysValidFakeExtensionManager: IExtensionManager // 實作 IExtensionManager 介面
{
pubic bool IsValid(string fileName)
{
return true;
}
}
在測試程式中，可以自由設定假物件方法被呼叫時，要回傳什麼值。也就是 FakeExtensionManager 的 WillBeValid，這樣代表這個虛設常式類別可以在多個測試案例中重複使用。
另外要留意的是，透過建構函式中使用參數來注入，這設計使得這些參數成為了必要的依賴，這是設計上的選擇，將使得使用者必須為每個特定的依賴傳入參數。
關於建構函式注入的警告
透過建構函式注入假物件，可能會衍生問題。如果類別需要多個虛設常式，加入越來越多的建構函式就會越來越困難。
例如 LogAnalyzer 除了原本的檔案類型管理器，還額外需要依賴 Web 和 Log 服務，那麼建構函式可能如下所示：public LogAnalyzer(IExtensionManager mgr, ILog logger, IWebService service) { manager = mgr; log = logger; svc = service; }解決這個問題的其中一個方式，就是建立一個特殊類別，用來裝載要初始化被測試類別所需的所有值。這也叫稱為參數物件重構（parameter object refactoring）。
另一個可行方案是控制反轉（Inversion of Control, IoC）容器，利用特殊的工廠方法。可以到 這裡 了解更多。何時該使用建構函式注入
作者的經驗是，除非使用控制反轉（IoC）容器框架來初始化物件，否則使用建構函式會讓測試程式看起來更笨拙，但是，但是但是但是但是，作者表示通常還是會選擇使用建構函式注入，因為在 API 的可讀性跟語意上，這方式所帶來的影響是最小的。
用假物件來模擬異常
來看一個簡單的範例，在這個範例會說明，如何透過設定假物件來拋出例外。
假設需求：當檔案類型管理器拋出一個例外，期望被測試類別應該回傳 false，而不是把例外直接往外拋。（實務中不建議這樣處理例外）
[Test]
public void IsValidFileName_ExtManagerThrowsException_ReturnsFalse()
{
FakeExtensionManager myFakeManager = new FakeExtensionManager();
myFakeManager.WillThrow = new Exception("This is fake");
LogAnalyzer log = new LogAnalyzer(myFakeManager);
bool result = log.IsValidLogFileName("anything.anyextension");
Assert.False(result);
}
internal class FakeExtensionManager: IExtensionManager
{
public bool WillBeValid = false;
public Exception WillThrow = null;
public bool IsValid(string fileName)
{
if (WillThrow != null)
{
throw WillThrow;
}
return WillBeValid;
}
}
為了讓這個測試通過，你必須在被測試方法中增加一個例外處理的 try-catch，在 catch 區塊中回傳 false。
(β3) 透過屬性 get 或 set 注入假物件
這個方式是為每一個相依的物件建立一個對應的 get 與 set 屬性，然後在測試過程中使用這些相依物件。
你的測試程式會與上述建構函式注入程式碼很類似（同樣都是使用依賴注入（Dependency Injection）的技術），但更好讀，更容易撰寫，因為每個測試可以根據需求來設定自己需要的屬性。
使用屬性進行依賴注入。這方式比建構函式注入更加簡單，因為每個測試可以根據需求來設定自己需要的屬性。
β3.1: 透過在被測試類別中，增加一個新屬性來注入假物件
public class LogAnalyzer
{
private IExtensionManager manager;
public LogAnalyzer()
{
manager = new FileExtensionManager();
}
public IExtensionManager ExtensionManager // 允許透過屬性來設定相依物件
{
get { return manager; }
set { manager = value; }
}
public bool IsValidLogFileName(string fileName)
{
return manager.IsValid(fileName);
}
}
[Test]
public void IsValidName_SupportedExtension_ReturnsTrue()
{
// 設定虛設常式（stub），確保回傳 true，可以參照前面的作法，如：β2.1 [Test]
...
// 建立 analyzer，依賴注入虛設常式（stub)
LogAnalyzer log = new LogAnalyzer();
log.ExtensionManager = someFakeManagerCreatedEarlier; // 注入虛設常式
// Assert 邏輯
...
}
就像建構函式注入一樣，屬性注入也定義了哪些相依物件是必須的，哪些是非必需的，這都會對 API 的設計造成影響。透過使用屬性來定義相依物件的方式，其實是在表達一件事：要使用這個類型的物件，這個相依並不一定非得存在不可。
- 何時該使用屬性注入
如果你想表達出對被測試類別來說，這個相依物件並非是必要的，或是在測試過程中這個相依物件會被建立預設的物件執行個體，進而避免造成測試問題。
(β4) 在呼叫方法之前才注入假物件
這一節所討論的場景是針對：當你要對某一個物件進行操作前，才獲得該物件的執行個體，而不是取用透過建構函式傳入的參數或屬性注入的物件。在前面幾個小節的討論中，假物件都是在測試開始進行之前，在被測試類別以外就設定好假物件，再透過建構函式或屬性注入。
- A. 使用工廠類別
- B. 在發布版本中隱藏接縫
- C. 不同的中間層深度等級（淺到深）
- D. 偽造方法——使用一個區域的工廠方法（擷取與覆寫）
A. 使用工廠類別
在這種情況下，回到了最基本的設計方式，在被測試類別的建構函式中，初始化管理執行個體，但這個執行個體來自工廠類別。
在測試程式中，將設定工廠別（在這個例子中，使用一個靜態方法回傳一個實作 IExtensionManager 的物件執行個體）回傳一個虛設常式物件，而不是實際產品程式碼中實作 IExtensionManager 的類別。
在測試程式中，因為設定了工廠類別的行為，因此測試過程可取得一個虛設常式物件。當在產品程式碼中，透過該工廠類別取得物件時，仍會回傳原本產品程式中所預期的物件，而非虛設常式物件。
β4.A.1: 在測試執行過程中，設定工廠類別回傳一個虛設常式物件
public class LogAnalyzer
{
private IExtensionmanager manager;
public LogAnalyzer()
{
manager = ExtensionManagerFactory.Create(); // 在產品程式中使用工廠類別
}
public bool IsValidLogFileName(string fileName)
{
return manager.IsValid(fileName) && Path.GetFileNameWithoutExtension(fileName).Length > 5;
}
}
[Test]
public void IsValidFileName_SupportedExtension_ReturnsTrue()
{
// 設定虛設常式（stub），確保回傳 true
...
ExtensionManagerFactory.SetManager(myFakeManager); // 為這個測試設定虛設常式，並注入工廠類別
// 建立 analyzer，依賴注入虛設常式（stub)
LogAnalyzer log = new LogAnalyzer();
// Assert 邏輯
...
}
class ExtensionManagerFactory
{
private IExtensionManager customManager = null;
public IExtensionManager Create() // 調整工廠設計，使其能使用與回傳自訂的管理器物件
{
if (customManager != null)
{
return customManager;
}
return new FileExtensionManager();
}
public void SetManager(IExtensionManager mgr)
{
customManager = mgr;
}
}
工廠類別千變萬化，這只是其中一個最簡單的呈現。
你唯一要確認的事就是一旦你使用了這些模式，要在工廠類別中加入一個接縫，讓它們可以回傳自訂的虛設常式。
B. 在發布版本中隱藏接縫
使用 [Conditional] 特性：DEBUG 和 RELEASE 是最常見的。
在編譯時，如果這個編譯標記不存在，帶標記方法的呼叫端就不會包含在這個編譯的版本中。例如，在編譯 release 版本時，下面這個方法所有的呼叫行為都會被移除，而這個方法內容仍會保留下來。
[Conditional("DEBUG")]
public void DoSomething()
{
...
}
C. 不同的中間層深度等級（淺到深）
這一節中所處理的中間層深度等級與之前幾章節不同，在每一個不同的深度等級，可以選擇產生一個假物件或是虛設常式。
以下列出了三種可在程式中回傳虛設常式的中間層深度等級（淺至深）：
- 層次深度 1：針對類別中的 FileExtensionManager 變數
- 可進行的操作：新增一個建構函式參數，以便傳入相依物件。此時只有被測試類別中的一個成員是偽造的，其餘的程式碼皆保持不變。
- 層次深度 2：針對從工廠注入被測試類別的相依物件
- 可進行的操作：透過工廠類別的賦值方法，設定一個假的相依物件。此時工廠內的成員是偽造的，被測試類別完全不需要調整。
- 層次深度 3：針對返回相依物件的工廠類別可進行的操作
- 可進行的操作：將工廠類別直接替換成一個假工廠，假工廠會回傳假的相依物件。此時測試執行過程中，工廠是假的，回傳的物件也是偽造的，被測試類別完全不需要調整。
關於中間層的使用，你需要了解的是，當控制的中間層越深，你對被測試程式的控制能力就越大，但這也同時帶來副作用：中間層越深，測試程式就越難理解，越難找到插入接縫位置。訣竅是要在複雜度與掌控能力之間找到平衡點。程式依然好讀易懂，同時還能完全控制被測試程式的情況。
D. 偽造方法——使用一個區域的工廠方法（擷取與覆寫）
這個跟前面所提的中間層深度相較，並不屬於任何一層，它在接近被測試程式的表層上建立了一個全新的中間層。越接近程式碼的表層，你為了模擬相依物件所需要修改的內容越少。
使用這種方式，你透過被測試類別的一個區域 虛擬方法（virtual method） 作為工廠方法，以獲取檔案類型管理器的物件執行個體。因為這個方法被宣告成虛擬方法，所以它可以在衍生子類別中被覆寫內容，這就產生了所需要的接縫。
你可以在測試中新增一個類別，繼承自被測試類別，並覆寫其虛擬的工廠方法，由此注入假相依物件。
接著，測試程式就可以針對這個新的衍生子類別進行測試。這樣的工廠方法也可以稱為回傳虛設常式方法。
當繼承被測試類別後，你就可以複寫其虛擬的工廠方法，並自行決定回傳任何一個實作了 IExtensionManager 介面的物件，接著針對剛新增的衍生類別進行測試。
在測試中使用工廠方法步驟：
- 在被測試類別中：
- 新增一個新的 虛擬工廠方法，回傳一個實際的物件執行個體
- 在產品程式碼中正常使用該工廠方法
- 在測試專案中：
- 新增一個類別
- 新的類別 繼承 被測試類別
- 針對你要取代的介面（IExtensionManager）型別，建立一個公開的爛位
- 覆寫 虛擬的工廠方法
- 回傳公開的欄位
- 在測試程式中：
- 初始化一個實作 IExtensionManager 的虛設常式物件
- 初始化在測試專案中所新增的衍生類別物件，而非被測試類別
- 將虛設常式物件，透過衍生類別物件的公開欄位，注入至衍生類別物件中
β4.D.1: 偽造一個工廠方法
public class LogAnalyzerUsingFactoryMethod
{
public bool IsValidLogFileName(string fileName)
{
return GetManager().IsValid(fileName); // 使用虛擬的 GetManager() 方法
}
protected virtual IExtensionManager GetManager()
{
return new FileExtensionManager(); // 回傳寫死的值
}
}
[TestFixture]
public class LogAnalyzerTests
{
[Test]
public void overrideTest()
{
FakeExtensionmanager stub = new FakeExtensionManager();
stub.WillBeValid = true;
TestableLogAnalyzer logan = new TestableLogAnalyzer(stub); // 初始化繼承自被測試類別的衍生類別物件
bool result = logan.IsValidLogFileName("file.ext");
Assert.True(result);
}
}
class TestableLogAnalyzer: LogAnalyzerUsingFactoryMethod
{
public TestableLogAnalyzer(IExtensionManager mgr)
{
manager = mgr;
}
public IExtensionManager = Manager;
protected override IExtensionManager GetManager() // 回傳你指定的值
{
return Manager;
}
}
internal class FakeExtensionManager: IExtensionManager // 與前面例子相同不需改變
{
...
}
這個技巧稱為「擷取與覆寫（Extract and Override）」，試過幾次你會發現這方法使用上超級簡易。
- 何時該使用這種擷取與覆寫
「擷取與覆寫」非常適合用來模擬提供給被測試類別的 輸入（input），但如果要拿來驗證被測試程式對相依物件的呼叫，卻十分不便。
如果你需要模擬回傳值，或是直接回傳介面，擷取與覆寫都很合適。但如果是要確認被測試類別與相依物件之間的互動，這方式就不適用。
三、克服封裝的問題
- 使用 internal 和 [InternalsVisibleTo]
- 使用 [Conditional] 特性
- 使用 #if 和 #endif 進行條件編譯
四、小節
在開始官方總結之前，我先說一下我自己的心得：「這章節好難！爆幹難！」我也鉅細靡遺看了三遍還似懂非懂，仍在揣摩那傳說中的藝術。不過呢～在心裡埋顆種子，也許哪天突然就發芽了！
在前面兩個章節（Chap 1 & 2），你開始撰寫簡單的測試程式，但有些相依物件要解決、替換。在本章，你已經學會如何使用介面和繼承，透過虛設常式物件來解決直接相依的問題。
在程式中注入虛設常式物件的方式有很多種，關鍵在於找到合適的中間層，或是建立出這個中間層，然後把它拿來當作接縫，在執行過程注入虛設常式內。
因為假物件並不一定為虛設常式（stub）或模擬物件（mock），因此我們命名時習慣用 Fake。
擷取與覆寫方式，是為被測試類別模擬輸入的極佳方式。
和經典的物件導向相比，可測試的物件導向設計（TOOD）有些有趣的優點，如讓程式兼具可測試性與可維護性。
下一章節，我們將了解和依賴相關的其他問題，並找到解決這些問題的方式。
