只聘請願意寫單元測試的軟體工程師

Jan. 30 17:48~19:00

▲古早味的VB程式

一個測試，各自表述

一位從事測試工作的朋友告訴Teddy，他在應徵工作時主管告訴他，公司的工程師都有做單元測試。到職之後，有一天朋友去找工程師…

朋友：我可以看一下你寫的單元測試程式嗎？

工程師：什麼程式？

朋友：單元測試程式，主管說你們都有做單元測試。

工程師：喔，單元測試喔。有啊，不過我們都是手動測試，自己手動測自己寫的function。

朋友：（黑人問號？？？）

***

自動化

單元測試是指對程式可執行的最小單位（單元）進行測試，可能是function或是object。一般而言單元測試如果沒有特別強調，預設狀況下應該會認為是自動化單元測試，也就是透過單元測試程式碼（unit testing code）去測試生產程式碼（production code）。

Teddy剛開始寫第一個自動化單元測試是N年前還在用VB 6.0開發Windows軟體的時候。寫過VB（非現在的VB.NET）程式的鄉民都知道，VB的程式邏輯很容易和UI元件產生緊密耦合，必須透過使用者介面來測試系統功能。Teddy從台北工專電子科畢業，然後當兵，到退伍，寫了好幾年的VB程式，獨自開發7~8個不同的系統。

一開始也都是自己手動測試系統功能，但是時間久了之後覺得好累，因為手動的「廻歸測試」簡直不是人幹的工作，太花時間、累人又無聊。但是如果不手動「廻歸測試」，什麼時候修改功能造成bug又不知道。等到客戶踩到雷回報錯誤，又有漫長的除錯工作和加不完的班，也是很討厭。

後來JUnit被發明且流行之後，Teddy才知道原來有自動化單元測試這種東西。可惜當時沒有免費的VB Unit工具，從網路上花了幾十塊美元買了一個VB Unit工具，正要興高采烈的寫單元測試時，才發現寸步難行。因為VB程式的邏輯很容易全部都寫在使用者介面中，根本無法單獨測試邏輯。

***

相依性分離

後來才知道原來VB可以寫OCX與DLL元件，沒有使用者介面的程式邏輯可以寫在Class裡面包成DLL（VB 6也有Class，支援介面繼承但不支援實作繼承）。把程式邏輯從UI元件抽離，改放到DLL之後，便可以對DLL寫自動化單元測試。

有了這次經驗，開始愛上單元測試。雖然自動化單元測試不能完全取代透過使用者介面執行的驗收測試，但可以大幅減少手動測試的數量，而且當單元測試案例執行失敗時，也可以減少除錯的時間。

另外還有一個好處，就是為了提高自動化測試的程度，程式的模組化也提升。以前Teddy很瞧不起VB 6，認為它不是一個「完整的物件導向語言」（因為不支援實作繼承）。但後來又讀了〈Design Patters〉，才知道原來應該多用物件聚合少用實作繼承。VB 6也可以寫出很棒的物件導向程式以及套用設計模式。

***

今天暫時停止

近20年後的今天，在台灣會寫單元測試的工程師已經很多了……才怪。和20年前相比的確是變多了，但是以全體程式開發人員當分母來看，工作上把「撰寫單元測試當作軟體開發不可分割的一部分」的工程師還是少數。這種狀況不知道是要歸咎於台灣的資訊教育有待加強，還是職場的大環境不支持。

一個沒有自動化單元測試的團隊，手邊的軟體不是「軟體」，而是「硬體」，硬梆梆的沒人想改也不敢改。這種情況還學人家談什麼敏捷開發、擁抱改變，早點洗洗睡吧。

***

軟體工程師要提升自己的價值，除了學好物件導向技術以外，最立竿見影的方法，就是開始寫自動化單元測試。

***

友藏內心獨白：一試成主顧。