為什麼這篇c#單元測試mock鄉民發文收入到精華區：因為在c#單元測試mock這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者derekhsu (華麗的天下無雙)看板Soft_Job標題[討論] 多少公司有執行單元測試 分...
關於自動化測試可以參考我多年前的拙作
https://www.ptt.cc/bbs/Soft_Job/M.1338221262.A.0AC.html
不過現在我們在討論單元測試，所以我將把我的文章內容縮小到「單元測試」
上面。
我待過四間公司，寫過C#, PHP, Python, Java，而這四家公司不管小接案公司
，網路公司，跨國軟體公司或是大型傳統產業，通通都沒有養成所有人普遍撰寫
單元測試的習慣，倒是我聽說一些朋友在比較偏小型的start up或是小型軟體
公司，比較有在做Unit Test。
很多人在談Unit Test的時候會把Unit Test跟Integration Test混在一起，然後
說Unit Test要付出很多effort，實際上，他是把Unit Test跟Integration Test
混在一起講了。
雖然這些這些公司都因為種種原因沒有做Unit Test的習慣，但是我在這四間公司
裡面全部都有自己做Unit Test，而即使有做Unit Test，我的品質與速度都比其
他人要快。
很多人在做Unit Test有一個盲點，就是為了做單元測試而做單元測試，因為上面
一個方案下來，說我們的專案要有幾個test case，要達到多少coverage rate，
這樣才叫做品質好，卻經常沒有從Unit Test的ROI出發。
另外一項造成Unit Test會花上許多時間的原因，就是物件的依賴程度太高，又
不懂得使用Mocking技術或是沒有讓程式有足夠的測試力，導致做單元測試會影響
到整體開發時程，這樣單元測試就變成累贅了。
「你終究要測試你的程式的，為什麼不做單元測試呢？」
如果你的單元測試是為了減少你的測試時間用的，減少測試時間進而減少整體
開發時間，那你為什麼不做呢？
給一些還沒有做單元測試的朋友一些體會到單元測試的切入點：
1. bug的單元測試
如果發現bug，嘗試用單元測試的方式找到那段有問題的程式碼，然後撰寫一個
單元測試程式，以後迴歸測試時要執行這個測試。
2. 減少耗時的I/O
network, storage這些東西都會造成你後續測試的時候消耗很多時間，透過mocking
技術， 機制將這些I/O的部分都去除掉，每次測試執行時間可能從幾分鐘縮短到幾秒
，這會是天差地別的差距。
3. 選擇依賴關係高的程式來做
很多人在寫單元測試的時候會挑外圍的程式來說，這些外圍程式大多沒有太多的依賴
關係，所以出問題的機會也少，程式也相對容易理解，反觀那些高依賴關係的程式，
由於跟其他類別之間大量耦合，要測試裡面的內容相對來說困難許多，透過mocking
來切割待測類別與其他類別之間的依賴關係，這樣就不用花這麼多時間準備整合測試
資料。
反觀依賴度低的類別，測試資料準備與驗證相對簡單，雖然做單元測試也快，但ROI
卻很低，做久了，會很沒有成就感。
4. 思考單元測試減少的載入時間
除非你有用JRebel或是類似的東西，否則你在開發Spring Java程式的時候不免必須
不斷restart你的application或是你的container去bootstrap Spring managed beans
，這些在測試階段會花上非常多的時間。
當然Spring有提供JUnitRunner或AbstractTestNGSpringContextTests來供你產生單元
測試用的spring context，但當你類別多的時候還是很花時間的，這時候如果透過具備
Mocking功能的單元測試來完成你程式碼的測試作業，將可以大幅縮短之後的測試時間。
以上這幾點達到的測試覆蓋率可能不太高，但你應該會找到程式要測試的重點，至於
單元測試是要程式開發前(TDD)或是開發之後做，這要看你使用什麼樣的mocking技術。
重點是不要為了去做Test而去Unit Test，重點是分析這樣做以後能達到多少ROI。
最後再來談談「單元」，每個人對於單元的定義可能都有所不同，但基本上的認知是，
單元測試是在測試「程式碼」最小界定範圍為「一個function」或是一個類別，所以
單元測試的目的在於測試function或class是否有達到預期。
當然function或class之間是有dependency存在的，單元測試的目的是去除這些
dependency讓整個測試可重複執行並且不會因為其他單元的問題或不存在而造成
待側單元的錯誤。事實上我認為單元測試最大的關鍵是怎麼透過各種方法去消滅
這些dependency的能力，實際上你學的不是測試方法，而是mocking方法。
如果你是用Java的話推薦使用無敵mocking framework JMockit，完全不用對你
現有的程式進行改造，一樣可以mocking。
其他透過撰寫測試的過程當中知道怎麼樣去規劃元件之類的好處我就不說了，
台灣這邊的軟體產業之所以會有種種問題，一部分就因為對於unit test帶來
的好處與方法沒有正確的認知所導致。
--
～四十八個德瑞克～http://blog.derekhsu.homeip.net
馬皇本紀：http://blog.derekhsu.homeip.net/2009/08/821
藍澤光的身世之謎：http://blog.derekhsu.homeip.net/2010/09/1610
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.181.111.225
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1478187696.A.46A.html
推 jaspreme206: 推11/03 23:45
推 GoalBased: 舊系統，一開始沒特別注重耦合相依的問題，到後來要11/03 23:46
→ GoalBased: 寫單元測試成本一定會很高，大家都要學如何重構、物件 11/03 23:47
→ GoalBased: 導向，之後在學單元測試的東西 11/03 23:47
高耦合度的程式是無法做unit test的，你對多個類別耦合在一起的程式寫程式進行測試那就叫做integration test，不是unit test。
至於要不要重構這件事，如我所說，這跟你用的是什麼mocking tool有關，如果是
JMockit，那別擔心，你的程式就算是垃圾都不用重構也可以去除所有dependeny來做
unit test。
如果沒有這種framework可以用(C# https://www.typemock.com/isolator-product-page
這個可以試試看，但這是commerical的），unit test帶來的好處是refactor之後的
更好的系統架構。
※ 編輯: derekhsu (175.181.111.225), 11/03/2016 23:54:43
→ GoalBased: 怎麼在系統明明沒問題的情況下說服上面做這件事情..11/03 23:51
推 pttworld: 推。但可論述本人做單元測試與不做二者開發時程比較。11/04 00:19
→ pttworld: 與其他開發者的效率比較不是單元測試而是經驗。11/04 00:21
推 jackblack: 偷偷推 Mockito11/04 00:25
推 Chris926926: 推，感謝分享11/04 00:58
推 tails32100: 推推，感謝分享11/04 01:10
推 blackacre: 離題問一下D大，你現在主力開發語言是什麼 P還是J? 11/04 04:36
Java→ atst2: 為什麼一直在UT上爭執開發速度啊？11/04 07:01
→ atst2: UT的目的在於提高產出的品質與完成度不是嗎?11/04 07:03
不對，因為實務上，時間跟品質不能兼得推 Trick: 就是醬沒錯 11/04 07:18
推 etoanik: Python有推薦的嗎? 11/04 08:09
推 SHANGOYANYI: 偷推 mockito +1 XD 11/04 09:07
推 gmoz: 感謝分享11/04 10:31
推 atpx: 感謝分享11/04 10:48
推 kimkao: 偷推Mockito +2 XD 11/04 11:29
→ derekhsu: 我要反推Mokito，JMockit各方面屌打Mokito……只是不能 11/04 13:32
→ derekhsu: 拿來在Android上跑11/04 13:32
※ 編輯: derekhsu (49.216.129.242), 11/04/2016 13:34:07推 UncleB: Unit Test-->Integration Test-->System test 11/04 15:56
推 sean0430: 寫Android推Mockito+3 XD 11/04 18:08
推 orange7986: 推 11/04 21:09
推 turelyman: 很詳細的分享 11/05 07:02
推 ntddt: 推分享~ 11/05 16:34
推 flowheart: 推 11/06 22:33
推 wddx: 推 謝謝分享 11/07 01:31
推 siriusu: 推 11/07 09:43