爲何咱們要作單元測試？(二)

 引子

當我第一篇博客原題叫作<爲何.NET開發者都不寫單元測試>,個人本意是想跟.NET技術圈的朋友們一塊兒交流,爲何過去在.NET開發中不多用到單元測試,以後，在公衆號文章和博客園的留言中，許多開發者紛紛表示，單元測試做爲企業行爲，與實施的技術棧不一樣，不是開發者我的行爲，實施單元測試花費的時間精力過於龐大，與實際效果嚴重不對等，並且若是過分的採用單元測試，也會增長新的測試點，由於單元測試代碼自己就須要進行測試等。

從這些回覆能夠看出，程序員要不要編寫單元測試這種話題，大概作傳統開發時，問程序員要不要寫項目文檔同樣充滿爭議。正如你們都深入明白項目文檔的重要性，可是一旦程序員須要編寫項目文檔了，每每會對這個事情產生抵觸情緒，這其實是絕大多數開發者的通病。

單元測試也是這樣的矛盾糾結體。在長沙.net技術社區就有很多朋友紛紛表示，他們都曾經試圖在公司推進單元測試的應用，可是受到了自上而下的反對聲，最終迫於壓力，只能放棄。 而之因此阻力這麼大，其主要緣由是編寫單元測試會增長額外的時間，由於編寫單元測試，不只僅只是編寫一個簡單的測試入口，而是一系列步驟，可是領導要求在最短的時間看到效果，而且有的領導還常常改變主意，若是設計了一個優秀的單元測試用例，有時候甚至會由於沒法適應需求的變化，而最終腐爛。 

顯然，使用單元測試和更高的單元測試的代碼覆蓋率，大概是一個試金石。過去在長沙還不多有企業會問開發者會不會使用單元測試，可是近年來愈來愈多的企業會問候選人代碼覆蓋率的問題，因此做爲開發者，能夠嘗試從單元測試開始,努力提升本身的代碼習慣，編寫更加高質量的代碼。

有哪些公司在要求編寫單元測試？

過去，單元測試一直是專業軟件公司的首選，有一位原諾基亞核心部門的開發者說爲諾基亞內部，對單元測試的要求很高，雖然沒有達到百分之百，但也有很是高的要求，在《構建之法》中，鄒欣老師介紹了微軟的開發實踐，也對單元測試覆蓋率提出了很高的要求。 固然有的讀者或許會嗤之以鼻，這些都是古典軟件公司，舉這些例子有什麼意義呢？中國式IT 公司，哪家都是996，哪裏還有什麼時間實行單元測試？ 

然而，優秀的互聯網公司都開始推行devops 做爲企業信息化建設過程當中的最佳實踐標準，持續集成和持續發佈都對單元測試有很高的要求，例如在阿里巴巴java 開發者手冊中，就明確提出瞭如下一系列指標，要求開發者務必採用單元測試方法，儘量的提升代碼質量。

1. 【強制】好的單元測試必須遵照 AIR 原則。

2. ...此處省略七百字

3. 【推薦】單元測試的基本目標：語句覆蓋率達到 70% ；核心模塊的語句覆蓋率和分支覆蓋率都要達到 100% 

參見原文阿里巴巴Java 開發者手冊，因而可知，單元測試已經做爲一種行之有效的手段，顯然已經成爲了中國優秀互聯網企業的必然之選。

單元測試中的代碼覆蓋率有什麼用？

代碼覆蓋率是單元測試的重要衡量指標，反映了單元測試中測試用例對被測代碼的覆蓋程度，是對代碼的測試質量衡量的重要指標。

在十年前，博客園《代碼覆蓋率淺談》(參考資料1）一文，深刻淺出的介紹了單元測試的四種類型， 包括語句覆蓋，斷定覆蓋，條件覆蓋，路徑覆蓋四種類型，做者指出，單元測試覆蓋率結果，有如下做用：

a. 覆蓋率數據只能表明你測試過哪些代碼，不能表明你是否測試好這些代碼。 

b. 不要過於相信覆蓋率數據。

c. 不要只拿語句覆蓋率(行覆蓋率)來考覈你的測試人員。 

d. 路徑覆蓋率 > 斷定覆蓋 > 語句覆蓋 

e. 測試人員不能盲目追求代碼覆蓋率，而應該想辦法設計更多更好的案例，哪怕多設計出來的案例對覆蓋率一點影響也沒有。 

在軟件開發過程當中盲目的追求的高代碼覆蓋率，每每得不償失，尤爲是爲了提升代碼覆蓋率而作的單元測試，每每只會成爲累贅。

合理的操做形式應該是基於實際用例出發，設定更多的用例場景，實現基於用戶場景驅動的單元測試覆蓋，像在阿里巴巴開發者手冊中說的，測試人員與開發人員配合，共同完成測試用例覆蓋，就是一種不錯的應用實踐。

固然，即使測試缺位，開發者也徹底應該主動的承擔更多單元測試的職能，儘量多的思考用戶場景中可能存在的變數。

編寫好的單元測試的一些小技巧

　　技巧一，多看書確定是不錯的

有朋友問，怎麼寫好單元測試？有什麼書推薦麼？我很慚愧，我本身的代碼單元測試的覆蓋率還至關低，可能沒辦法給出指導，我想多看書確定是沒錯的，而編寫單元測試的書，還挺多的，例如這一本，《單元測試的藝術》，一看就是基於C#的，能夠試一試。  

 而想入單元測試的門，能夠看看我後面找到的一系列引文，相信能給你帶來方便。  

　　技巧二，運用測試框架 

一、單元測試框架：XUnit、NUnit、MSTest等.

二、測試運行工具：xunit.runner.visualstudio 。相似如：Resharper的xUnit runner插件。 

三、模擬框架：Moq、RhinoMocks、NSubstitute、FakeItEasy等。   

　　技巧三，靈活的運用事務回滾或內存數據庫，避免單元測試數據污染正常數據

前者是阿里巴巴開發者手冊中提到的一種方法，在有的場景下也挺實用的，不過有開發者指出，可使用模擬內存數據庫來解決這個問題更爲穩當，例如使用Effort.EF6，經過nuget獲取，使得建立一個僞造的、供EF容易使用的內存數據庫成爲可能。與這相似的，還可使用HttpSimulator來模擬http 請求。  

　　技巧四，使用依賴注入和單例模式改良不可測代碼

靜態類爲代碼編寫帶來了許多便利，可是也使得代碼測試變得相對困難，而使用單例模式進行改良則使得操做更可控。 

總結 

人生苦短，擼碼不易。從選擇成爲開發者的那一天起，咱們就被迫承受了許多壓力，尤爲是技術發展的不肯定性，更是如此，你永遠也不知道本身當下的選擇是否正確，說不定你今天最爲熟悉的技術或框架，明天就涼涼了。尤爲是如今的各類自媒體，時不時的發幾篇文章來輸出焦慮，恨不得每天說優勝劣汰才能得到讀者的關注通常，讓開發者們壓力更大。 

我以爲，技術是解決問題的方法，而良好的代碼習慣則是自身心法，尤爲是單元測試，更是一種好習慣，先別總想着擔憂本身被淘汰，努力的使本身習慣更好，總會得到無窮收穫。

 

參考資料1:《代碼覆蓋率淺談》.

參考資料2：《代碼覆蓋率強迫症》.
參考資料3: 《代碼覆蓋率 (Code Coverage)從簡到繁》

參考資料4，《C#單元測試，帶你快速入門》.

【版權聲明】 

本博客版權歸做者和博客園共有，做品來自於長沙.NET技術社區成員【鄒溪源】，有興趣瞭解長沙.NET技術社區詳情，請關注公衆號【DotNET技術圈】,做品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。