因此如果覺得測試是狗屁的,可以跳過不看這篇文章;
而如果想要了解更多測試的知識,可以參考一下:
- 測試大家族=UT+整合測試+TDD+其他族繁不及備載
- UT(單元測試)
- UT是寫程式都要會,但不是一開始就需要會的,應該是等到你能夠寫出可運行的程式後再來學習。
- 至於要會到什麼程度?要不要常常用到?就看工作性質和自我要求了。測試工程師不用說了,那就是他們在做的事情;而開發工程師的話,會UT可以讓你在重構或是思考系統設計時,有個切入點。而且也讓你可以確保說該物件在你修改前後都可以有相同功能性。
- 基本上,UT較容易直觀撰寫,不太需要花太多精神寫太多東西,測試較快速。
- 要小心的地方在於,有些時候有些東西過於單元化/模組化,是否是有必要的?為了UT而生出一堆的介面,是否真的必要?
- 整合測試(Integration Testing)
- 整合測試也是一定要會,但要到什麼程度和用到的程度要看職位。
- 如果你今天只是一般的PG,那麼不太需要花太多心思在整合測試上面,因為你可能碰得層面不廣,或是還不太了解整體系統,反而可能做了過多的整合測試,但如果能夠了解基本的整合測試,會對於你在重構時,因為舊有的程式耦合嚴重,需要先用整合測試來確保舊有程式的功能,才好做之後重構的驗收;
- 但如果你是SD、SA或PM等級的話,那麼應該會較常用到,而整合測試也有助於幫你揭露出你的系統是否有設計過當或是缺失的部份。
- 基本上,整合測試較不容易撰寫,因為相關的元件較多,測試也較慢,但其實拜現在運算速度提升所賜,速度上也不會真的多慢。
- 要小心的地方在於,因為相關元件很多,常常牽一髮而動全身,常常需要修改整合測試的程式,但真的該測試有必要嗎?
- TDD(測試導向開發)
- 俗語說:「見山是山,見山不是山,見山又是山」,又說:「盡信書,不如無書。」我認為最能夠表達目前我對於TDD的看法。
- TDD是一個好武器,但是就只是個武器,別把他過於神格化,對於大部份的工作都有著不小的幫助。
- 尤其是對於已經很多人寫過的系統領域來說更是如此,可以更有效率的開發,但是如果是全新的領域來說,就未必了,雖然步調很快,但是很有可能走偏方向或是繞了遠路。
- 建議如果是全新的領域,先好好的研究一下其他解法後,再使用TDD,而使用期間,也應該隨時跳出來看看目前是否有走偏。
- 我還是認為所有工程師都應該了解什麼是TDD,最好也都有TDD的經驗,而至於最後要用多少TDD在你自己的專案當中,應該是依專案依工程師自身的想法或團隊的想法來決定較好。
因此TDD已死了嗎?不,我不這麼認為,因為TDD的裡面還是有個TEST。
除非你連TEST的價值都不認同,那麼TDD也許才真的是死了。
只是到了那時,你的CODE還能夠算是真的活著嗎?
相關參考:
[懶人包]DHH: TDD is dead. Long live testing. 懶人包整理
[30天快速上手TDD]目錄與附錄
沒有留言:
張貼留言