我從2003年開始接觸單元測試(Unit Test)和持續整合(Continuous Integration,CI)。在這麼多年的實戰經驗中，深刻的感受到測試所展現的威力和種種的好處。之前不論是在JAVA或.NET團隊，都不斷宣揚測試是我們的護身符;只有被測試解救的人才會真正地了解，它才是原碼的背後英雄。
2003年時我在中研院進行實驗室資訊管理系統(LIMS)的開發。因專案很大，有請顧問導入流程和Framework，包含Struts,Hibernate,Spring,Unit Test 和 CI。而我的第一支測試碼也是在不情願和抗拒的情況下寫出來的。為何會不情願呢？當時認為還要多花時間寫測試碼，而且測試碼有時候不好寫，久了就開始偷懶，最後乾脆不寫了。 這也是大多數團隊遇到寫測試時常有的通病，有時組員三不五時還會抱怨，時程已經很趕了，可否能省略測試碼。可以，但是這個測試債有一天一定要還，還的人也許不是你，而是下一個倒楣鬼。
開發團隊在導入單元測試時，一定要有一位導師來負責監控組員所寫的測試，那位導師要非常懂測試，而且是位堅持原則而不易妥協的人。我們當年就有一位導師綽號為"叫獸"-愛叫的猛獸. 只要你不寫測試，而且程式碼覆蓋率低於90%，你就等著被吼，那時的團隊就是這樣被逼出來的。測試寫久了，就越寫越快，最後也就習慣了，而且使用Test-Driven Development(TDD)的開發方式，開發速度就更快了。
實驗室是很精密的單位，不能容許些微的差錯。程式碼也是一樣，一旦出錯有時侯是會釀成災難的。在多人共同開發的專案中，常常某位成員將API改了，就會導致一連串的連鎖錯誤，而且細微的錯誤更是無法立即檢查出來；曾經就發生過一件事，我把自己開發計算試劑存量的API改了，自己的單元測試也測試通過，上了CI後，以為一定OK，馬上就可上線，沒想到半小時後，CI郤回報錯誤，有人的測試碼沒有過。因為某些試劑是不能使用新版API的計算方式，因為試劑太多了，我沒有想到還有這些例外情況，還好大家都有寫測試，否則一旦上線，該試劑的存量錯誤不會立即知道，可能要等1~2星期有明顯錯誤時，使用者才會查覺，等到那時已經太晚了!!
測試救了我，也讓我了解不能沒有測試!
最後就套這一句話:
剛開始你會死命地抗拒它，之後呢你會慢慢地習慣它，到最後你會發現不能沒有它!
大家是否有想過，如果我們在學習程式語言時，老師就先教我們先寫測試碼，把寫測試碼當做開發程式的標準習慣，或許現在的軟體專案品質就不會那麼差了。不幸地，現在的情況剛好相反!
PS:那位"叫獸"就是訂便當的站長
沒有留言:
張貼留言