難得看到這麼精彩的討論, 而我非常同意 TonyQ 的看法 特別同意 1. unit test 不是各處都適用 2. unit test 不是萬靈丹, 他只是用來取代人類重覆同一個動作容易出錯的特性 3. unit test 視需求再配合其他的 QA 機制 這邊補充一點我對 unit test 的想法 想像一家公司有 5 個 team 各自開發各自的 service 彼此之間是有相依性的, 但是彼此不見得會熟悉對方的程式 他們有共同的 continuous build system, 並且每次 build 玩也都會自動跑 unit test 當你的程式碼通過 code review, 可以送進 repository 之後 你可以很容易的就知道有沒有 break 別人的 build, 有沒有 break 別人的 test case 如此便可在 release cycle 之間快速的決定要先 revert 還是能夠提供 quick fix 想像這些 service 都是很花時間 deploy 並且需要複雜的設定讓彼此相連的 有時候你只是想要很簡單的測試是不是某個資料驗證的 function 寫對了 把 service 跑起來驗證 (如果寫錯了還要重覆幾次) vs 寫你手動測會測的資料作成 unit test, 跑 unit test 好幾次 這時候開發時間 / 測試時間的衡量之下, 就可能會讓人喜歡上 unit test 再搬個教科書上的說法 unit test 是讓這個模組的原作者寫下該注意的事項 而手動驗證常常是接棒的人, 甚至是不相關的人臆測做的測試 與其讓不瞭解的人盲目的測試, 不如讓清楚事件始末的原作者先立好標準 我自己是從懷疑, 學習, 一直到受到大量的好處之後 最後才相信 unit test 這種做法有其可取之處 瞭解了好處, 知道在什麼地方是他的著力點, 才能安心使用 此外, 建議先去瞭解現階段的 unit test framework 能做到什麼事 並且瞭解一般來說要搭配什麼樣的動作一起做 (continuous build ? code review ? ... etc.) 最後才是評估自身的需求, 是不是有需要建置這些系統, 是不是帶來夠多的好處導入需要多少的教育訓練等等 這時候下定論要不要使用 unit test, 才不會誤用 or 浪費 :) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.32