unit test 與 AsUnit 3.0 - 關於 testing 與 test-driven的兩三事 (3/3)

testing這件事對許多工程師來說都是：知道它很重要，但從來不覺得應該去做。

在瞭解如何使用 AsUnit這樣一個 test framework後，接者就可以來談談目前一般人進行testing的方式。

比較傳統的做法是先寫程式，然後再做 unit test，也就是程式碼寫好後再用一堆 test case去驗証它的正確性，這種做法初看是非常合理的，也符合一般常見的專案開發流程，先規畫、再寫code、最後測試，然後上線(我們就叫這種為 waterfall開發法)

但這種做法也有不少的缺點，最明顯的一個就是等到全部的code都寫好時才要進行測試，往往會覺得無從下手，因此此時可能已經有數十個class，而且彼此的關連極深，根本不知道該怎麼測起，搞不好連當初寫的工程師自已都忘了某個class是做什麼用的(別笑，你試試看自已寫個class不加註解，然後半年後再拿出來，看看你還能記得多少內容或理解它在做什麼)。

另一個麻煩就是此時才進行測試，即使發現了錯誤，恐怕也很難修改，或是能改但成本變的很大，因為這時一改恐怕就要牽動好幾個其它class，天知道改了這裏其它地方會不會爆炸。

有鑑於此，90年代未期開始出現一種新的聲音，強調不如在寫程式前先把 test case寫好，然後再以通過測試為目標去開發程式，這就是所謂的 test-driven design。

舉個簡單的例子，以前面的money class為例，傳統的劇情是這樣：

1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元

2、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}

3、寫好後用幾組不同的數字傳入 addMoney() 去看看結果是否正確

而在 test-driven的劇情則是這樣：

1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元

2、接者我先寫些測試的case 做為將來測試使用，例如

3、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}

但由於我已經知道將來會怎麼測試它，因此在寫的過程中就會特別留意傳入的參數與回傳的資料型態等細節要符合這個測試的期盼。

在 test-driven 的開發手法下，工程師寫程式是為了能百分之百通過 test case，因此在整個開發過程中就有了明確的依歸，只要test case有要求，就要在程式碼裏面完成(而且一定要完成)，而 test case 沒提到的事，就沒有那麼高的priority可以丟一邊先不管，因此只要 test case 寫的夠週全，將來成品就一定可用。

另一方面，在寫 test case的過程中，工程師也會有機會先想清楚整個過程，有點類似 forsee/preview 將來程式完成的樣子，然後根據他在腦子中的觀察，去寫下所有功能的 test case，這很像是讓建築師在還沒動手蓋房子前，就在腦中冥想出未來成屋的樣子，然後照者在腦中看到的畫面去建這棟房子；這與傳統先動手蓋房子等到落成那天才能看到全貌是完全不一樣的兩回事。

最後再仔細想想，反正不論早晚都是要寫 test case (當然如果你壓根就沒打算做 testing那就另當別論)，如果早寫可以帶來這些額外的好處，而晚寫卻要面臨種種風險，任何聰明快樂又有遠見的工程師應該都知道該怎麼選吧？

而 test-driven正巧也是近年來漸成主流的 agile development 重心之一，其中最為人所知的方法論就是 eXtreme Programmg (XP編程)，當然 agile development 是個大題目，值得另外撰文聊聊，但這裏的重點只有一個：越來越多的工程師在經歷了幾十年的專案開發歲月後，終於發現先寫 test case帶來的效益是何其之大。

現在flash coders也有了 asUnit 3這個重量級的協力工具，要怎麼發揮它的妙用就看個人囉

note: 寫完這篇心中已經浮起另一個題目 > toward an agile flash development 聽起來還挺炫的吧？(只是有沒有時間寫就看老天了)