[30天快速上手TDD][Day 2]Unit Testing 簡介

[30天快速上手TDD][Day 2]Unit Testing 簡介

大綱

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

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

  1. Why
  2. What
  3. Where
  4. Who
  5. When

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

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

 

前言

單元測試,是 developer 最該寫的測試程式,卻也是最容易被忽略的測試。

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

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

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

 

Why

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

Day2 開發常見問題

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

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

Day2 Unit Test解決常見的問題

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

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

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

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

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

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

 

What

Unit Test 的定義與基本準則,如下圖所示:

Day2 Unit Test準則

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

Unit Test的特性,一個字:FIRST。如下圖所示:

Day2 FIRST

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

 

Where

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

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

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

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

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

  1. 驗證目標物件的回傳值,如下圖所示:
    Day2 測試回傳值
  2. 驗證目標物件的狀態改變,如下圖所示:
    Day2 測試狀態
  3. 驗證目標物件與外部相依介面的互動方式,如下圖所示:
    Day2 測試互動

 

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 is based on working test cases」。

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

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。