Unit Test Via Visual Studio-Part1

標籤：

寫在開頭：Coding ain‘t done until all the tests run. No unit test no BB.

-------------------------------------------------------------

本文主要介紹如何在Visual Studio（2012+）下面做單元測試。主要以下內容：

1. 單元測試介紹
2. 單元測試的基本特點
3. 使用VS Stub進行單元測試

單元測試介紹

測試類型很多，單元測試是開發人員使用程式自動化的測試自己的代碼，用一張圖說明：

上面的method代表的是一個獨立的邏輯，並不是說所有的方法都需要測試，比如私人方法，他應該屬於其他的獨立邏輯，可以通過其他的方法就行測試

單元測試是代碼品質的強有力的保證，是重構代碼的信心保障，好的單元測試個人認為應該有以下的特點：

1. 運行速度要快，如果你的測試回合需要一整天，以後肯定不願意寫case，也不願意再運行和維護
2. 測試case應該互相不依賴，不要出現運行A case 先得運行B case的情況
3. 測試case不應該依賴外部資源，比如service，DB，應該隨時都可以運行（比如斷網）
4. 單元測試應該和生產代碼一樣重要，要隨著代碼的維護而維護

在VS中使用Stub特性進行單元測試：

1. 先寫一段用於測試的代碼

一個用於發送email的介面

   /// <summary>    /// interface of email handler    /// </summary>    public interface IEmail    {        bool SendEmail(string reveiver, string emailBody, string subject);    }

Email發送的實現，調用Email service發送郵件

    /// <summary>    /// real email handler    /// </summary>    class EmailImp : IEmail    {        public bool SendEmail(string reveiver, string emailBody, string subject)        {            //call email remote service here to send email             return true;        }    }

業務通知類，調用EmailImp發送郵件，發送成功，返回1，失敗返回0，當然真正的業務肯定要做其他事情。

 public class Notifier    {        public IEmail EmailHandler { get; set; }        public Notifier()        {            this.EmailHandler = new EmailImp();        }        public int Notify()        {            var sendResult = this.EmailHandler.SendEmail("[email protected]", "email body", "emailSubject");            if (sendResult)            {                return 1;            }            else            {                return 0;            }        }    }

2. 現在要測試Notify方法，簡單的步驟，產生測試solution和基本測試代碼：

3. 上面的Notify至少應該對應兩個Case：

1. 當Email Service返回true
2. 當Emial Service返回false

上面說到，單元測試不應該依賴於外部Service,DB.等。但是程式一般肯定依賴這些。如果這些外部Service down了。DBdown了。程式怎麼測試。在測試的時候如何控制Email Service 按照我們的需要來返回True、False。這就是Stub要解決的問題。Stub是存根打樁的意思，打樁是測試裡面很重要的一個概念。

4. VS可以通過增加Fake程式集來完成對程式的Stub：

5. 增加fake程式集之後就可以看到：

6. 接下來sub的使用,直接通過代碼來展示

上面的例子很清楚，兩個case完全不依賴於外部email service。隨心所欲的指定email service 的傳回值，從而很輕鬆的驗證了我們自己的邏輯。

Stub主要思想就是在運行時針對介面動態注入，動態用我們指定的Stub類來替換真正的執行類來完成我們指定的功能。

想通過Stub進行測試，被Fake的對象必須基於介面編程。

當然基於介面編程，上面的Stub程式員也可以自己實現，何必呢，VS已經幫我們實現了。

那問題來了。如果代碼沒有基於介面進行編程，怎麼辦？是不是沒有辦法像Stub這麼進行替換類比呢。下一篇文章再介紹另外一個功能:Shim.

 

Unit Test Via Visual Studio-Part1