測試的哲學

最近手上的一個專案漸入高潮，各方人馬分頭進行的各模組也開始進入整合階段，引發一個有趣的議題。

系統被拆解成多個模組分工開發，但模組間有很密切的相關性。例如: 模組A寫入的資料，要變成模組B報表的來源；模組C修改的基本資料檔，會左右模組A寫入資料的邏輯，也影響模組B報表產出的結果。

為求開發速度，開發初期各模組團隊是各自獨立進行的，準備測試資料時，以各模組自己可以運作為目標。由於尚未跟其他相關模組整合(例如: 模組A寫入資料前，要先經過模組C驗證資料有效性，但模組C根本還沒寫好，所以就先寫一段假邏輯替代或索性跳過驗證)，寫入資料庫的資料在完整性及合理性尚未達到系統最終要求。加上開發期間程式修修改改，程式錯誤時也塞入了一些邏輯不符的資料沒有清除。

可以想見，現階段資料庫裡的資料千奇百怪，模組B產生的報表自然一塌糊塗，明明依著系統規格書的邏輯寫，因資料不合理，就跑出讓人吐血的結果。最理想的狀況當然是要求所有資料得符合系統規範，不該是NULL的就不得留白，數字大小也必須落在合理範圍。但從實務面來說，這等同於將整合測試的部分工作提前，要求重整資料勢必要先中斷各模組開發人員的工作，停下來協調各模組以產生合理資料，這個停頓時間看來不會太短，將嚴重影響各組的既定時程規劃。

看來是一個兩難抉擇，所以變成了可以討論的話題。大家討論了一下，發現彼此看法不盡相同，形成了有趣的對照，也反映了不同的開發哲學。

有人贊成依原先計劃，待整合測試階段再驗證結果正確性。理由是這樣較不會破壞各組既有的時程規劃，搞亂大伙漸入佳境的工作節奏，系統的完成進度也較能符合預期。再者，及時有具體的成果(不論結果對錯)產出，對於"安定人心"也有很大的指標性意義。(不要小看這一點，有實戰經驗的人應該會同意"心理層面"因素對專案成敗的影響並不亞於時程、功能、效能等議題)

而我，或許是受了TDD(Test Driven Development)的荼毒，深信程式應該一開始就要做對(Do Right At First Time, DRAFT)，錯誤愈遲發現、愈晚修正，代價將呈等比級數倍增。例如: 現在因為測試資料不正確，在寫第一支報表時無法檢視結果，未察覺某段邏輯不正確，那麼同樣的錯誤邏輯觀念就會被複製到第二支、第三支報表裡，待進入整合測試階段時才發現，就得回頭重新檢查修改所有的程式。

而從另一個角度來看，先略過正確性檢查的開發方式在時程上的表現雖較亮眼，時程到了"東西都有如期交出"，但其正確性卻不被保證，也許整合測試後還要花上可觀的時間將程式結果修到正確。換句話說，"時程一如預期"可能只是假象，因為當初時程要求的一定是指某個時點應是交付"正確可用的程式"，而非"看起來可以跑的程式"。當外界對程式品質失去信心，降低了對開發人員的信任度，對開發團隊而言，會是一項危機。話雖如此，老執著於測試正確性、開發進度停頓、大半天程式連影子都看不到的開發團隊，實在也高明不到哪裡去...

這番分析下來，兩種做法實在沒有明顯的優劣，頗像傳統測試哲學對決TDD的泰勢。TDD如果只有優點沒有缺點，早就變成大家奉行不渝的鐵律，事實上，TDD測試優先的做法，撰寫測試付出的額外成本十分可觀，時程不易壓縮且人力耗用大，嚇走了不少決策者與開發者。

大家面對這樣的情境時，會採取何種策略呢?