導入Unit Test

在實際專案中幾次導入Unit Test的失敗，確實值得讓人省思。Unit Test並不是沒有缺點，我們曾在這篇文章中討論過，我覺得導入失敗的幾個主要的原因如下：
1. Unit Test的缺點你一定會遇到，但是Unit Test的優點你不一定會得到
2. Legacy code
3. 人們天生不太願意接受改變

1. Unit Test的缺點你一定會遇到，但是Unit Test的優點你不一定會得到 (Unit Test的優缺點)
首先，如果要寫Unit Test你的開發時間一定會變長，這是必然的結果；光是這一點Manager就不一定會同意了，在專案的時辰壓力下，不寫Unit Test時就已經很趕的話，何況還要多寫Unit Test。
而且當production code需要修改，testing code往往也需要跟著修改，在軟體開發的階段，遭遇修改也可以說是必然的結果，導入Unit Test確實也是會在軟體需要修改時，增加修改的時間。
再來，你的programmers必須先經過training才能寫出高品質的testable code和testing code，這也是另一個令人卻步的原因。
而Unit Test的優點呢？Unit Test可以在開發初期就找到Bugs的前提是：test case的quality要好，test coverage要夠。如果做不到這點，Unit Test帶來的好處你就拿不到。

2. Legacy code
再有大量Legacy code的project中導入Unit Test的難度又更高了，聽過有成功導入Unit Test的projects都是屬於比較新的projects。
畢竟你為了要做Unit Test而去修改一段已經可以work、也沒有bugs的code，似乎不太合乎常理；再來，如果是因為要做Unit Test而改了legacy production code，那麼QA是不是要重測？因為我們也不能保證是否會改出bug。花了那麼多resource重寫、重測只是為了要做Unit Test；所以我認為legacy code是導入Unit Test最大的阻礙。

3. 人們天生不太願意接受改變
對有些人來說，改變某種程度上是對過去的否定，如果過去的做法沒甚麼不好，為什麼需要改變呢？尤其在改變之後又不一定會得到好處，這也是導入Unit Test的難處之一。

根據我的觀察，導入Unit Test幾乎都是programmers一頭熱，Managers卻是不以為然。但對於programmers來說，會寫Unit Test是在履歷上會有加分，也難怪programmers會比較想推Unit Test。

所以我覺得面臨現實中導入Unit Test的種種困難，所採用的折衷方案如下：
1. 先導入範圍更廣的Integration test，再導入Unit Test (確保改出bug的機率會降低，QA的重測也可以用automation integration test來重測，減少人力成本)

2. 犧牲unit test的coverage，只讓新寫的module導入Unit Test (避免修改legacy code)