iT邦幫忙

DAY 2
12

30天快速上手TDD系列 第 2

[Day 2]Unit Testing 簡介

Testing的第一個切入點:單元測試。

本篇文章將針對單元測試進行簡介,主要內容包含了:
Why, What, Where, Who, When。

而How的部分,屬於實作,將於下一篇文章介紹工具與簡單的範例。

最後會提到「測試案例」所代表的意義與其重要性。

上一篇文章:[Day 1]TDD guidance
@前言
單元測試,是developer最該寫的測試程式,卻也是最容易被忽略的測試。

大家常碰到的測試相關問題是:

  1. 往往一堆人寫測試程式時,自以為是在寫單元測試,卻壓根就不是單元測試,而是整合測試。
  2. production code是我寫的,如果測試程式也是我寫,那有什麼意義?所以應該給QA/QE來寫才能測出盲點。
  3. 我程式都寫完了,跑起來也都對,這時寫測試程式一點意義都沒有。
  4. 測試程式要跑好久。
  5. 沒有測試環境,要怎麼寫測試。

看完這幾篇單元測試的相關文章後,希望大家可以獲得一些想法,解決這些問題。

@Why
先舉幾個在開發上常見的問題:

  1. 怎麼讓UI, Service, Data Access平行開發?
  2. 要到真實環境方能測試程式無誤
  3. 頁面發生錯誤,到底是誰錯了?
  4. 交付的程式,到底測過哪些東西了?
  5. 我改了這支程式,會不會害別的程式掛掉?

這些問題,可以有哪些Unit Test相關的方式來解決:

  1. Unit Test中使用mock object,達到關注點分離
  2. Unit Test使用mock object來模擬外部回傳的資料
  3. 把input值當做test case,跑一次Unit Test
  4. 交付的程式,包括Unit Test程式碼
  5. 改完程式就跑一次Unit Test吧

總而言之,沒有被測試涵蓋到的程式碼,即使它可能是對的,也沒人敢拍胸脯保證。而有了測試案例來輔助說明與保護,至少可以拍胸脯保證,在這樣的測試案例下,這個物件的設定,肯定如同預期般執行。

而單元測試可以提供迴歸測試的保護,在每一次異動完程式,可以單鍵執行就知道是否破壞了原本對物件行為的預期。

單元測試可以透過一些輔助設計,來達到與外部環境、服務、相依隔絕,而僅測試該物件本身的邏輯,以及與外部的互動是否符合預期。

造成問題的測試案例,往往是最珍貴的,因為最具代表性,也最具價值。因為他提供了我們修正bug的方向以及指標。而針對發生問題的測試案例,來執行單元測試,馬上就可以知道是否是該物件的內部問題。

最後,單元測試由於具備與外界服務、相依隔絕的特性,所以可以幫助撰寫實際的物件時,具有可測試性、低耦合性,彼此之間只相依於抽象或介面。進而透過IoC的設計,讓我們可以做到關注點分離,讓開發各個物件的developer,可以透過介面來溝通,不相依於彼此實作,就能平行開發。

@What
Unit Test的定義與基本準則:

  1. 一個測試案例只測一種方法
  2. 最小的測試單位
  3. 不與外部(包括檔案、資料庫、網路、服務、物件、類別)直接相依
  4. 不具備邏輯
  5. 測試案例之間相依性為零

Unit Test的特性,一個字:FIRST

  1. Fast:快速。
  2. Independent:獨立。
  3. Repeatable:可重複。
  4. Self-Validating:可反應驗證結果。單元測試不論成功或失敗,都應該要從測試的reporting直接瞭解其意義或失敗原因。
  5. Timely:及時。單元測試應該恰好在使其通過的production code之前撰寫。

@Where
單元測試的範圍,以定義來說,單元測試是最小的測試單位,在物件導向中,就是測試一個方法。而方法一定會在某個物件上(即使是靜態方法,也是在型別物件上)。

所以,單元測試通常就只關注在測試的目標物件上,而不管目標物件以外的東西,例如:目標物件所相依的實體物件、相依服務、相依資源、相依環境等等...

單元測試,簡單的說,就是用來模擬外部如何使用這個目標物件,或是如何與這個目標物件互動。所以我們所撰寫的單元測試程式,就是模擬與目標物件互動的程式。測試案例,就是該互動下的情境。接著驗證物件的行為是否符合我們預期。

因此,單元測試程式,既然是模擬外部如何使用目標物件,所以也只會針對目標物件對外開放的方法。

而基本上,單元測試透過哪些方式去驗證物件的行為符合預期呢?簡單來說,有三種:

  1. 驗證目標物件的回傳值

  2. 驗證目標物件的狀態改變

  3. 驗證目標物件與外部相依介面的互動方式

@Who
單元測試該由誰來撰寫,就如同前言所說,最應該撰寫的是developer,而非QA/QE。

就如@Where段落所說,單元測試簡單的說,是我們在設計物件的時候,預期外部該如何使用這個物件,進而衍生出物件該提供什麼樣的功能、具備什麼樣的行為。正因為物件的設計人、使用人,都是developer,所以單元測試的程式,當然由developer來設計,最為妥當。尤其由用的人來寫,最為精準。

歸納幾個基本要點:

  1. 想要達到什麼需求,就是測試案例。而物件的設計,只是為了滿足需求,需求即測試案例。即production code只為了滿足測試程式上的測試案例。
  2. 設計物件的人員,才能知道物件該怎麼給外面使用。
  3. 由外部使用物件的角度來設計測試案例。

@When
撰寫單元測試的時機點,簡單分成三個:

  1. 外部需要使用物件,並對其執行結果有所預期時(developing)
  2. feature的異動時(modifying)
  3. 出現非預期執行結果時(bug fixing)

想清楚,外部的需求是什麼,才能設計出符合需求的物件。

當需求異動時,自然需要針對新的需求,來設計新的測試程式,因為這樣才能驅使目標物件行為的改變。

當出現非預期的執行結果時,通常代表目標物件有著非預期的行為發生,有可能是當初測試案例不足,所以要增加我們的「預期」。

也有可能是當初預期的結果就錯了,那其實就可以當作是第二點,需求的異動。(當然對使用端來說,還是屬於bug,但對物件設計來說,測試案例方向就錯了,當然無法苛求目標物件的行為要對...測試程式與實際物件是一起活著的)

@Test Cases的意義
大家買過3C產品或電器吧,基本上拿到一個東西,我們都會先看使用說明書。

大家肯定也寫過一堆「系統分析書」、「程式規格書」、「SA/SD文件」等等...但這些文件,跟最後線上的程式碼,究竟有多少是相同的呢?文件越詳細,代表後面修改的effort越大。

因為軟體設計,本來就是個需求頻繁變動的過程,往往大家只想「凍結需求」,卻很常因為「凍結需求」搞到作出來的系統難用,因為不符合使用者需求。(我們期望的是,每一次的需求異動,都是軟體進化的動力,每一次的異動,都是品質的累積,以及更符合使用者的需求。)

而文件呢?只有一開始分析、設計爽的,因為程式碼寫下去,跟文件搭不搭的起來,只有三個人知道,一個已經離職了,一個是我,另一個我不能說。偷笑

鮮少會有文件跟著程式碼一直進行更新的。

但文件卻又是輔助瞭解與說明很重要的東西,那怎麼辦?很簡單,會一直活著的,就只有程式碼。要驗證程式碼是否符合我們預期,最簡單的方式,就是用程式碼驗證它的行為,一翻兩瞪眼,現在的物件究竟滿足了那些功能,哪些情境下可以跑出預期結果,測試案例一目了然。

所以,測試案例的意義與價值是什麼?

  1. 可自動執行、馬上執行、快速執行的物件使用說明書,不會有過期或漏了更新的問題
  2. 不管什麼情況發生,不管在什麼環境底下,都能確保其執行結果如同預期

程式碼即文件,高興什麼時候產生文件,就什麼時候產生,保證即時、可運作、童叟無欺。測試案例上面有的,肯定work,而測試案例上面沒有的,不一定會錯,但不打包票。

@小結
一句話總結:「working software based on working test cases

working software是TDD的整個骨架,也是user最需要的東西。


上一篇
[Day 1]TDD guidance
下一篇
[Day 3]動手寫Unit Test
系列文
30天快速上手TDD31
1
pajace2001
iT邦研究生 1 級 ‧ 2012-10-10 01:13:59

沙發
怎麼覺得樓主寫文章的風格好像一位IT前輩91哥的風格,連圖都很像XDXD

就是91 iT邦研究生 4 級‧ 2012-10-10 01:25:43 檢舉

驚 沒想到一眼就被看穿身份了。

這樣我就不能當蒙面加菲貓了啊!

0
kirkchen
iT邦新手 3 級 ‧ 2012-10-10 01:15:31

樓主就是91哥阿 XD

pajace2001 iT邦研究生 1 級‧ 2012-10-10 01:18:08 檢舉

毆飛.....hatelove 就是91哥喔~毆飛
小的真是有演不是泰山啊~原來91哥會用不同的ID 汗汗汗

1
ted99tw
iT邦高手 1 級 ‧ 2012-10-10 01:30:02

沙發

<span style="color: green;"><span style="font-size: 36px;">頂.禮.膜.拜!</span></span>

0
sp52005
iT邦新手 5 級 ‧ 2013-01-14 14:44:52

有神快拜!!簽名

我要留言

立即登入留言