我們在Day 4-Visual Studio 環境安裝與介紹第一隻測試專案 HelloBank (單元測試基礎-3)曾提過 HelloBank 的商業邏輯如下:
針對商業邏輯,本次測試專案方向是檢測 BankAccount 裡面的商業邏輯(存款、取款與轉帳);而測試項目中也分成檢測正常情況的結果(Day-5)與不合理情況的例外是否預期 (Day-7),然後為了精簡程式碼的書寫,把所有測試 Arrange 都會新增的 Account 物件撰寫在 SetUp 階段 (Day-6)。
因此,從實務上來分析商業邏輯需檢測的項目,應如下面所列的項目:
針對提款與存款測試方法實作可參照這幾天的範例,接下來針對最後的轉帳功能撰寫測試,而轉帳與提款、取款差別在於,轉帳在 Arrange 階段需準備另一個 BankAccount 物件,若不存在需有例外處理,如下:
// 正常情況的轉帳功能
[Test]
public void Transfering_Funds_Updates_Both_Account()
{
// Arrange
otherAccount = new BankAccount();
// Act
account.TransferFundsTo(otherAccount, 500);
// Assert
Assert.AreEqual(500, account.Balance);
Assert.AreEqual(500, otherAccount.Balance);
}
// 轉帳給不存在的帳戶情況
[Test]
public void Transfering_To_Non_Existing_Account_Throws()
{
// Act + Assert
Assert.Throws<ArgumentNullException>(() => account.TransferFundsTo(null, 2000));
}
總結目前單元測試基礎系列的文章,學到了以下幾點:
原始碼可參照這兩隻 GitHub 專案:
Day-8 StartUp:https://github.com/SunShineYen/HelloBankDay8-StratUp
Day-8 Final:https://github.com/SunShineYen/HelloBankDay8-Final
接下來的章節,會來開始探討實務面上必然會遇見的問題;舉例來說,我們所撰寫的商業邏輯幾乎都會引用第三方套件,第三方套件的出現會影響我們對測試的掌握度(換言之,就是可能套件出錯導致測試沒過)。因此,會探討如何使用假物件(Fake)的概念來把第三方套件的因素濾除。
如何在適當的時機點把第三方套件替換就需要考慮系統本身的設計框架,也就是俗稱的 Design Pattern(接下來的文章會以工廠模式為範例,若有餘力會進一步討論幾個作者工作上常用的設計模式);而抽離的手法也是有數種方式,而且還會依據手法的不同,對商業邏輯的干涉產生一定程度上的變化。
最後對於假物件有一定的認知之後,在實務上很可能會遇到需要建置大量的假物件,若採用人工的方式刻寫類別,很容易造成程式碼的複雜化,進而導致維護成本提高;因此,會核心技術後半段會介紹隔離框架 NSubstitute 並導入範例中,體會使用隔離框架與自己撰寫上的差異。