你的RP是由你的程序質量決定的。

——阿超

這一章講的是兩人合作，既然程序是兩個人寫的，那就會出現一個人寫的模塊被另一個人寫的模塊調用的情況。很多誤解、疏忽都發生在兩個模塊之間。如何能讓自己寫的模塊盡量無懈可擊？單元測試就是一個很有效的解決方案。

1.1  用VSTS寫單元測試

例子：我們寫一個比較常用的類型，看看它的單元測試應該怎么寫？比如在各種網站應用程序中都會用到的“用戶”這一類型。誰自告奮勇上來表演一下寫代碼？小飛，好，請上臺。

小飛創建了一個C#的類庫（Class Library），并寫了如代碼清單11-1的代碼：

namespace DemoUser

{

    public class User

    {

        public User(string userEmail)

        {

            m_email = userEmail;

        }

        private string m_email; //user email as user id

    }   

}

好，現在右鍵選中User，就可以看到“Create Unit Tests”的菜單，這樣就可以創建新的單元測試（如圖11-2所示）。

圖11-2  創建單元測試項目

創建單元測試后，注意到在Solution Explorer中出現了三個新的文件（如圖11-3所示）。

圖11-3  新的單元測試文件

Class1.cs是程序的文件，而Class1Test.cs是與之對應的單元測試文件。

DemoUser.vsmdi：測試管理文件。

Localtestrun.testrunconfig：本地測試運行設置文件。

如何管理設置文件呢？右鍵再選屬性（Property）并不對。你得雙擊文件才能進入管理及設置界面。在設置界面中，你可以讓單元測試產生“demouser.dll”的代碼覆蓋報告。

注意在單元測試中，VSTS自動為你生成了測試的骨架，但是你還是要自己做不少事情，最起碼要把那些//TODO的事情給做了（如代碼清單11-2所示）。在這個時候，單元測試還都是用的Assert. Inconclusive，表明這是一個未經驗證的單元測試。

/// <summary>

///A test for User (string)

///</summary>

[TestMethod()]

public void ConstructorTest()

{

string userEmail = null; // TODO: Initialize to an appropriate

// value

 

User target = new User(userEmail);

// TODO: Implement code to verify target

Assert.Inconclusive("TODO: Implement code to verify target");

}

進行簡單的修改后，我們得到了一個如代碼清單11-3正式的單元測試：

        [TestMethod()]

        public void ConstructorTest()

        {

            string userEmail = "someone@somewhere.com";

 

            User target = new User(userEmail);

 

            Assert.IsTrue(target != null);

        }

//我們還可以進一步測試E-mail是否的確是保存在User類型中。

 

解釋單元測試的結構

從上面這個例子可以看到創建單元測試函數的主要步驟：

（1）設置數據（一個假想的正確的E-mail地址）；

（2）使用被測試類型的功能（用E-mail地址來創建一個User類的實體）；

（3）比較實際結果和預期的結果（Assert.IsTrue(target!= null);）。

現在可以運行單元測試了，同時可以看看代碼覆蓋報告“code coverage report”，代碼百分之百地都被覆蓋了。

當然這時候的代碼還有很多情況沒有處理，同學們在臺下雜曰——

處理空的字符串，長度為零的字符串，都是空格的串……

小飛熟練地用Copy/Paste又寫了下面的三個測試，如代碼清單11-4所示。

        [TestMethod()]

        [ExpectedException(typeof (ArgumentNullException))]

        public void ConstructorTestNull()

        {

            User target = new User(null);

        }

 

        [TestMethod()]

        [ExpectedException(typeof(ArgumentException))]

        public void ConstructorTestEmpty()

        {

            User target = new User("");

        }

 

        [TestMethod()]

        [ExpectedException(typeof(ArgumentNullException))]

        public void ConstructorTestBlank()

        {

            User target = new User("     ");

        }

如果不修改類庫中的代碼，單元測試會報告這三個新的測試都失敗了。

小飛對代碼做了相應的修改。結果出了這樣的錯誤，見代碼清單11-5：

 

Test method UserTest.UserTest.ConstructorTestBlank threw exception System.ArgumentException, but exception System. ArgumentNull- Exception was expected. Exception message:  System.Argument- Exception: Value does not fall within the expected range.

大家定睛一看，原來小飛的Copy/Paste用了原來的ArgumentNullExcep- tion，而不是ArgumentException。

如果有人加了下面的代碼：

if (!m_email.Contains("@"))

{

   throw new ArgumentException();

}

這時，代碼覆蓋測試就會報告代碼覆蓋率是85%左右。那還得加上新的單元測試以保證所有的代碼都得到了基本的測試。

二柱：現在我知道為什么有些軟件寫了好幾年都沒有發布了，敢情他們都忙著寫單元測試了。

阿超：也許因為他們沒有在一開始就寫單元測試，所以后來有很多小強要處理。很多調查顯示，在軟件開發后期發現的Bug，修復起來要花更多的時間。

蕓蕓：這對我們設計人員有什么用呢？好像都是一些細節的東西。

阿超：在我們寫規格說明書（specification）的時候，要越詳細越好，最好你的各項要求都可以表達成單元測試的一個測試用例。

蕓蕓：如果不能表示為一個單元測試呢？

二柱：那就是你寫得還不夠細。

小飛：我大膽地說一句。如果是一個人寫寫程序玩玩，單元測試似乎不那么重要。

二柱：你可以大膽地對你的女朋友說：“我們只是玩一玩……”看看效果如何。

阿超：如果玩一玩，什么都不太重要。如果你寫的模塊會有不同的人，在不同的時間使用，那你最好把你這一“單元”要做的事，以及它不能做的事，用單元測試清晰地表達出來。

 

 

下面我們講講怎樣才算一個好的單元測試。

單元測試應該準確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：

單元測試應該在最低的功能/參數上驗證程序的正確性。

單元測試應該測試程序中最基本的單元——如在C++/C#/Java中的類，在此基礎上，可以測試一些系統中最基本的功能點（這些功能點由幾個基本類組成），從面向對象的設計原理出發，系統中最基本的功能點也應該由一個類及其方法來表現。單元測試要測試API中的每一個方法及每一個參數。

單元測試必須由最熟悉代碼的人（程序的作者）來寫。

代碼的作者最了解代碼的目的、特點和實現的局限性。所以，寫單元測試沒有比作者更適合的人選了。

問：如果我很忙，能不能讓別人代勞做單元測試？

答：如果忙到連單元測試都沒有時間做，那么你也沒有時間寫好這個功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測試的，但是，程序的作者還是要對單元測試負責。

最好是在設計的時候就寫好單元測試，這樣單元測試就能體現API的語義，如果沒有單元測試，語義的準確性就不能得到保障，以后會產生歧義。

單元測試過后，機器狀態保持不變。

這樣就可以不斷地運行單元測試，如果單元測試創建了臨時的文件或目錄，應該在Teardown階段把這些臨時的文件或目錄刪除。

如果單元測試在數據庫中創建或修改了記錄，那么也許要刪除這些記錄，或者每一個單元測試使用一個新的數據庫，這樣可以保證單元測試不受以前單元測試實例的干擾。

單元測試要快（一個測試運行時間是幾秒鐘，而不是幾分鐘）。

快，才能保證效率。因為一個軟件中有幾十個基本模塊（類），每個模塊又有幾個方法，基本上我們要求一個類的測試要在幾秒鐘內完成。如果軟件有相互獨立的幾個層次，那么在測試組中可以分類，如數據庫層次、網絡通信層次、客戶邏輯層次和用戶界面層次，可以分類運行測試，比如只修改了“用戶界面”的代碼，則只需運行“用戶界面”的單元測試。

單元測試應該產生可重復、一致的結果。

如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復的。

問：如果用隨機數以增加測試的真實性，好么？

答：一般情況下不好，如果某個隨機數導致程序出錯，但是下一次運行又不能重復這一錯誤，于事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發現所有的缺陷。

獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構造數據，以保持單元測試的獨立性。

程序中的各個模塊都是互相依賴的，否則它們就不會出現在一個程序中。一般情況下，單元測試中的模塊可以直接引用其他的模塊，并期待其他的模塊能返回正確的結果。

如果其他的模塊很不穩定，或者其他模塊運行比較費時（如進行網絡操作），而且對于本模塊的正確性并不起關鍵的作用，這時可以人為地構造數據以保證這個單元測試的獨立性。

單元測試應該覆蓋所有代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，單元測試必須測試公開的和私有的函數/方法。

單元測試必須覆蓋所測單元的所有代碼路徑。

問：啊！這樣豈不是要寫很多啰里啰唆的測試方法？

答：對，因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達，那你也許要想想是否可以把這個錯誤處理拿掉。

大栓：這對于那些愛寫復雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛煉。

阿超：對，把單元測試的責任和代碼作者綁定在一起后，代碼作者就能更真切地體會到復雜代碼的副作用，因為驗證復雜代碼的正確性要困難得多。要注意的一點是：100%的代碼覆蓋率并不等同于100%的正確性。在下面的情況下，100% 的覆蓋率和100% 的正確性不是同一回事:

     a) 代碼中并沒有處理錯誤情況。 例如代碼打開了文件，但是并沒有處理一些異常情況，例如文件不存在，權限有問題，等等

     b) 代碼中有效能問題，雖然代碼執行了，并且也正確地返回了。但是代碼執行得也許非常慢。

     c) 多線程環境中的同步問題, 這個問題和本地代碼執行與否關系不大。

     d) 其它和外部條件相關的問題 (例如和設備相關，和網絡相關的問題)

    

單元測試應該集成到自動測試的框架中。

另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行它，并且可以使單元測試每天都運行。每個人都可以隨時在自己的機器上運行。團隊一般是在每日構建中運行單元測試的，這樣每個單元測試的錯誤就能及時被發現并得到修改。

單元測試必須和產品代碼一起保存和維護。

單元測試必須和代碼一起進行版本維護。如果不是這樣，過了一陣，代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤，哪些是由于單元測試更新滯后造成的錯誤。這樣就失去了單元測試的意義，同時又給大家增加了負擔。如此折騰多次以后，大家就會覺得維護單元測試是一件很費時費力的事。

很多開發人員有這樣那樣的借口不去提高單元測試的覆蓋率, 其中一個就是: 這一部分代碼永遠測不到! 請看 MSDN 的視頻講解:

http://channel9.msdn.com/Events/Build/2012/3-015

 

1.3 回歸測試

在單元測試的基礎上, 我們就能夠建立關于這一模塊的回歸測試  (Regression Test).

 

Regress 的英語定義是： return to a worse or less developed state。是倒退、退化、退步的意思。

 

在軟件項目中，如果一個模塊或功能以前是正常工作的，但是在一個新的構建中出了問題，那這個模塊就出現了一個“退步”（Regression），從正常工作的穩定狀態退化到不正常工作的不穩定狀態。

 

在一個模塊的功能逐步完成的同時，與此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過，我們就得到了此模塊的功能基準 (Baseline) , 一個模塊的所有單元測試就是這個模塊最初的Baseline。

 

假如，在3.1.5版本，模塊A的測試用例125是通過的，但是測試人員發現在新的版本3.1.6，這個測試用例卻失敗了，這就是一個“倒退”。在新版本上運行所有已通過的測試用例以驗證有沒有“退化”情況發生，這個過程就是一個“Regression Test”。如果這樣的“倒退”是由于模塊的功能發生了正常變化（由于設計變更的原因）引起的，那么測試用例的基準就要修改，以便和新的功能保持一致。

 

針對一個Bug Fix, 我們也要作Regression Test。

（1）驗證新的代碼的確把缺陷改正了。

（2）同時要驗證新的代碼沒有把模塊的現有功能破壞，沒有Regression。

所以對于“回歸測試”中的“回歸”，我們可以理解為“回歸到以前不正常的狀態”。

回歸測試最好要自動化，因為這樣就可以對于每一個構建快速運行所有回歸測試，以保證盡早發現問題。單元測試是回歸測試的基礎.

 

在專注于模塊基本功能的單元測試之外, 還有功能測試 – 從用戶的角度檢查功能完成得怎么樣。  在微軟的實踐中，在一個項目的最后穩定階段，所有人都要參加全面的測試工作，把所有以前發現并修復的bug 找出來, 一個一個驗證, 以保證所有已經修復過的Bug的確得到了修復，并且沒有在最后一個版本中“復發”, 這是一個大規模的、全面的“回歸測試”。

 

光說不練怎么行，請看JUnit 教程：

　　https://www.tuicool.com/articles/fArMFjJ

　　http://www.rzrgm.cn/rocedu/p/6371315.html#SECUNITTEST

 

單元測試的實踐：詳細的 Java 示例   C++ 示例   從命令行開始逐步培養編程能力 Java