單元測試的藝術 - Chapter 2.2 第一次UnitTest重構

呼應上一張的流程，測試成功之後的下個步驟 : 重構。

其實只是要介紹一個普遍的情況，當想測試的參數多變的話，那不就要寫一堆TestCase嗎?

此時就會出現大量重複的程式碼，且如果參數改變時，所有的TestCase都必須修正，

當測試多達幾十個甚至上百個時，那麼維護就會是一個大問題。

因此作者馬上介紹如何使用參數來重構測試。

這是一開始建立的三個Test：

可以發現第二個和第三個測試都是比對回傳是否為True，只差在參數不同，

因此作者便把Attribute從[Test]改為[TestCase]，並加上參數，如下：

要特別注意的是，由於同一個Test傳入了兩種不同意義的參數進行測試(大寫與小寫)，

因此這個Test的名稱必須更加通用，才能讓人一看到測試名稱就知道大意。

接著進行測試，結果如下：

可以發現儘管將兩個Test合併成一個，但是在測試結果視窗中還是顯示三個結果，

要特別注意的是，兩個Test的名稱都會變成一樣了。

接著還有一個參數，能否更精簡呢？

畢竟都是呼叫同一個funtcion，只差在預期結果為false。

答案是可以的，修改如下：

除了剛剛提到的，Test名稱必須更加的通用之外，

Assert使用的function也不同了，由 True / False 改為 AreEqual，

並且[TestCase]中必須挾帶你的預期值，以便和測試結果比對。

修改後執行測試，結果如下：

看到這邊，我想到一個問題，既然三個Test名稱都一樣，

那如果其中一個錯誤，有辦法知道是哪一個嗎?

馬上來測試看看，我將預期值是false的.foo副檔名，改為預期值為true，

並執行測試，果然錯誤了：

但我點擊左側的失敗案例，卻只跳到右側第17行的位置，

即使是點擊測試成功的案例，也是跳到第17行的位置，代表都是同一個Test，

這樣該如何得知是哪一個測試案例參數錯誤呢?

這時請注意測試失敗時的詳細資訊，也就是左下角的地方：

("filewithBadExtension.foo",True)

這裡就看的到是哪一個測試參數失敗了，非常清楚。

到這裡，把所有對同一個function測試的參數條件都合併成一個，

Test的方法名稱也必須變得非常通用，看起來非常簡潔，

但我想對於Test名稱命名的能力就必須更強，才不會導致看的人理解錯誤，

後來又想到另一個濃縮撰寫的好處，

至少可以在同一個Test內就完成所有對這個function的測試，

只要這個Test錯誤，很快地就能縮小範圍到這個function上去debug。