在單元測試的推廣上常面臨的一些問題：
1. 開發期已經不夠了，該怎麼去做單元測試？
這個問題應該是大家最大的問題，如果有時間的話，有誰不想做到品質呢？但是PM開出來的時間就是這麼短，根本不太可能完成。當大家有這個疑問的時候，應該基本上都是對ＰＭ處於一種不信任的關係，甚至是有一點敵對的狀態，事實上，我覺得當ＰＭ或是工程師在評估工時的時候，應該「主動」把單元測試的時候估算進去，因為這個是提升品質的「必要」環節。一個不做單元測試的情況，基本上就是對自已的程式碼一種不負責任的態度，我曾經在一份工作上，主管單位為了要求提升各個工程師的品質，於是便要求寫發版驗証郵件，可是每一次驗證的時候都是相當累人的，且「不可以重用」，這個對每個工程師來說應該都是難以忍受的吧！
當沒有做單元測試的情況下，在每次發版的過程中，一但發生了問題，那接下來與QE來回間的時間成本，相信是絕對大於寫單元測試的，而且如果考慮到後續的維護或是在新人交接的部份，單元測試無疑都是可以大大的節省時間成本的。
只不過這些是較隱性的成本，需要去留意才可以發現這些事，但是一但注意到了，對於成本考慮的pm來說我想這個是具有相當大的吸引力的。
如果現行專案真的沒辦法讓你完全去做到單元測試，或是ＰＭ就是不能理解單元測試的重要性的話，我仍建議專注在「邏輯繁鎖」的類別或是「主要」類別都要做單元測試，而如果是在維護的話，則在每一次的維護時，都應該做單元測試，因為80%的BUG都出現在20%的程式碼內，要維護或是修改的邏輯亦是如此。
2. 外部的環境綁定太多，做單元測試很麻煩該怎麼辦？
在我的經驗裡，單元測試常常伴隨著「重構」。因為單元測試就像是種照妖鏡一般，他也可以用來檢視我們程式的架構是否夠良好，是否會彼此相依性過高。當你常常覺得，為什麼一個單元測試要測時，總是要麻煩的設定資料庫（或是設定其它的外部資源，如ＸＭＬ或是TXT等）那都是表示與外部相依過高。是否有辦法解決呢？其實是可以透過一些方法去解決(相依注入就是一個很棒的辦法)，以及利用其他的Test Framework去mock這些外部元件，用來可以快速的完成單元測試，解決每次都要設制外部環境的問題。這些都將在之後說明。
3. 單元測試的好處、壞處
就我的心得感覺而言好處有以下- 幫助建立信心
每一次修改過後，只要跑過一次單元測試，看到他們每個都變成了綠燈或是打勾的狀態，相當有提升士氣的作用。 - 發現異常
當程式碼在開發的過程中，難免會有修改的時候，一但修改發生的時候可以快速的檢視是否有修改異常的地方。 - 比註解更容易讓人理解程式碼的作用
透過單元測試可以簡單快速的讓人理解這段程式碼的作用、輸入及輸出結果，在交接上可以代替一部份的文件 - 提升程式架構能力
一個好測試的程式雖不見得等於好的程式，但是一個不好測試的程式架構，絕對對未來維護是個災難…而為了要能達成可測試或是容易測試的架構，在編寫上就容易去多思考些。
好處不好，但是缺點也是有的，自已感覺最明顯的一項就是：
- 花時間
根據我自已的經驗，花費的時間約是平時開發的時間要乘以二，不過這個跟熟練程度有關係，未來我如果更熟悉些或許可以更快。
沒有留言:
張貼留言