.NET重構—單元測試的程式碼重構

閱讀目錄：

• 1.開篇介紹
• 2.單元測試、測試用例程式碼重複問題（大量使用重複的Mock物件及測試資料）
  • 2.1.單元測試的繼承體系（利用超類來減少Mock物件的使用）
    • 2.1.1.公用的MOCK物件；
    • 2.1.2.公用的MOCK行為；
    • 2.1.3.公用的MOCK資料；
• 3.LINQ表示式的重構寫法（將必要的LINQ寫成普通的Function穿插在LINQ表示式中）
• 4.面向特定領域的單元測試框架（一切原則即是領域驅動）
  • 4.1.分散測試邏輯、日誌記錄（讓測試邏輯可以重組，記錄形式為領域模型）
  • 4.2.測試用例的資料重用（為自動化測試準備固定資料，建立Assert的比較測試資料）

1】開篇介紹

最近一段時間結束了一個Sprint，在這次的開發當中有些東西覺得還不錯有總結分享的價值，所以整理成本文；

重構已是老生常談的話題，我們或多或少對它有所瞭解但是對它的深刻理解恐怕需要一段實踐過後才能體會到；提到重構就不得不提為它保駕護航的大功臣單元測試，重構能有今天的風光影響力完全少不了單元測試的功勞；最近一段時間寫單元測試用例的時間遠超過我寫邏輯程式碼的時間和多的多的程式碼量，這是為什麼？我一開始很難給自己一個理由去做好這件事，心態上還是轉變不過來，可是每當我心浮氣躁的時候它總能給我點驚喜，讓我繼續下去，天生具有好奇心的程式設計師怎麼會就此結束呢，只有到達了一扇門之後我們回過頭來看一下走的路才能真正的明白這是條對的路還是錯的路；

單元測試簡單寫起來沒有什麼太大問題，但是我們不僅為了達到程式碼的100%覆蓋還要到達到邏輯的100%覆蓋，程式碼的覆蓋不代表邏輯的覆蓋；一個簡單的邏輯判斷雖然只有一行程式碼，但是裡面可能會有正反向很多種邏輯在裡面；比如：Order.ToString()簡單的程式碼，想要覆蓋很簡單，只要物件不為空都能正確的覆蓋到，但是如果我們沒有測試到它為NULL的情況下的邊界邏輯，這個時候我們就會漏掉這種可能會導致BUG的邏輯路徑；所以我們會盡可能的多去寫用例來達到最終的理想效果；

（總之把單元測試的所有精力集中在可能會出問題的地方，也是自己最擔心的地方，這個地方通常是邏輯比較複雜的地方；）

2】單元測試、測試用例程式碼重複問題（大量使用重複的Mock物件及測試資料）

單元測試程式碼中最常見的程式碼就是Mock或者Fake介面邏輯，那麼在一個具有上百個用例覆蓋的程式碼中會同時使用到一組相關的Mock介面物件，這無形中增加了我們編寫單元測試的效率給後期的維護測試用例帶來了很大的隱患及工作量；

單元測試程式碼的組成都是按照用例來劃分，一個用例可以用來包括一個單一入口的所有邏輯也可以是一個判斷分支的部分邏輯；為了構造一個能完美覆蓋的程式碼步驟，我們需要構建測試資料、Mock介面，劃分執行順序等等，那麼一旦被測試程式碼發生一點點的變化都會很大程度上影響測試程式碼，畢竟測試程式碼都是步步依賴的；

那麼我們應該最大程度的限制由於被測試程式碼的變動而引起的測試程式碼的變動，這個時候我們應該將重構應用到測試程式碼中；

2.1】單元測試的繼承體系（利用超類來減少Mock物件的使用）

將多個相關的測試用例程式碼通過超類的方式關聯起來統一管理將大大減少重複程式碼的構建；就跟我們重構普通程式碼一樣，將多個類之間共享的邏輯程式碼或者物件提取出來放到基類中；這當然也同樣適用於測試程式碼，只不過需要控制一些更測試相關的邏輯；

其實大部分重複的程式碼就是Mock介面的過程，我們需要將它的Mock過程精簡化，但是又不能太過於精簡，一切精簡的過程都是需要犧牲可觀察性；我們需要適當的平衡提取出來的物件個數，將它們放入基類中，然後在Mock的時候能通過一個簡單的方法就能獲取到一個Mock過後的物件；

下面我們來看一下提取公共部分到基類的一個 簡單過程，當然對於大專案而言不一定具有說服力，就當拋磚引玉吧；

2.1.1】公用的Mock物件

首要的任務就是將公共的Mock介面提取出來，因為這一類介面是肯定會在各個用例中共享的，提取過程過主要分為兩個重構過程；

第一：將用例中的公用介面放到類的宣告中，供所有用例使用；

第二：如果需要將公用介面提供給其他的單元測試使用，就需要提取出相關的測試基類；

我們先來看一下第一個過程，看一下測試示例程式碼：

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

namespace UnitTestRefactoring
{
    public class OrderService
    {
        private IServiceConnection ServiceConnection;
        private IServiceReader ServiceReader;
        private IServiceWriter ServiceWrite; 

        public OrderService(IServiceConnection connection, IServiceReader reader, IServiceWriter writer)
        {
            this.ServiceConnection = connection;
            this.ServiceReader = reader;
            this.ServiceWrite = writer;
        } 

        public bool GetOrders(string orderId)
        {
            if (string.IsNullOrWhiteSpace(orderId))
                return false;
            return true;
        }
    }
} 

這個類表示遠端Order服務，只有一個方法GetOrders，該方法可以根據OrderId來查詢Order資訊，為了簡單起見，如果返回true說明服務呼叫成功，如果返回false表示呼叫失敗；其中建構函式包含了三個介面，分別用來表示不同用途的介面抽象；IServiceConnection表示對遠端服務連結的抽象，IServiceReader表示對不同服務介面讀取的抽象，IServiceWriter表示對不同服務介面寫入的抽象；這麼做可以最大化的分解耦合；

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NSubstitute;
using UnitTestRefactoring; 

namespace UnitTestRefactoring.UnitTests
{
    [TestClass]
    public class OrderService_UnitTests
    {
        [TestMethod]
        public void OrderService_GetOrders_NormalFlows()
        {
            IServiceConnection mockServiceConnection = Substitute.For<IServiceConnection>();
            IServiceReader mockServiceReader = Substitute.For<IServiceReader>();
            IServiceWriter mockServiceWriter = Substitute.For<IServiceWriter>(); 

            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders("10293884"); 

            Assert.AreEqual(true, testResult);
        } 

        [TestMethod]
        public void OrderService_GetOrders_OrderIdIsNull()
        {
            IServiceConnection mockServiceConnection = Substitute.For<IServiceConnection>();
            IServiceReader mockServiceReader = Substitute.For<IServiceReader>();
            IServiceWriter mockServiceWriter = Substitute.For<IServiceWriter>(); 

            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders(string.Empty); 

            Assert.AreEqual(false, testResult);
        }
    }
} 

這個單元測試類是專門用來測試剛才那個OrderService的，裡面包括兩個GetOrders方法的測試用例；可以一目瞭然的看見，這兩個測試用例程式碼中都包含了對測試類的建構函式的引數介面Mock程式碼；

圖1：

像這種簡單的情況下，我們只需要將公共的部分拿出來放到測試的類中宣告，就可以公用這塊物件；

圖2：

這樣可以解決內部重複問題，但是這裡需要小心的地方是，當我們在不同的用例之間共享部分Mock邏輯的時候可能會出現問題；比如我們在OrderService_GetOrders_NormalFlows用例中，對IServiceConnection介面進行了部分行為的Mock但是當執行到OrderService_GetOrders_OrderIdIsNull用例時可能是用的我們上一次的Mock邏輯；所以這裡需要注意一下，當然如果設計合理的話是不太可能會出現這種問題的；單一職責原則只要滿足我們的介面是不會包含其他的邏輯在裡面，也不會出現在不同的用例之間共存相同的介面邏輯；同時也滿足介面隔離原則，就會更加對單元測試有利；

我們接著看一下第二個過程，看一下測試示例程式碼：

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

namespace UnitTestRefactoring
{
    public class ProductService
    {
        private IServiceConnection ServiceConnection;
        private IServiceReader ServiceReader;
        private IServiceWriter ServiceWrite; 

        public ProductService(IServiceConnection connection, IServiceReader reader, IServiceWriter writer)
        {
            this.ServiceConnection = connection;
            this.ServiceReader = reader;
            this.ServiceWrite = writer;
        } 

        public bool GetProduct(string productId)
        {
            if (string.IsNullOrWhiteSpace(productId))
                return false;
            return true;
        }
    }
} 

這個是表示Product服務，建構函式中同樣和之前的OrderService一樣的引數列表，然後就是一個簡單的GetProduct方法；

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NSubstitute;
using UnitTestRefactoring; 

namespace UnitTestRefactoring.UnitTests
{
    [TestClass]
    public class ProductService_UnitTests
    {
        IServiceConnection mockServiceConnection = Substitute.For<IServiceConnection>();
        IServiceReader mockServiceReader = Substitute.For<IServiceReader>();
        IServiceWriter mockServiceWriter = Substitute.For<IServiceWriter>(); 

        [TestMethod]
        public void ProductService_GetProduct_NormalFlows()
        {
            ProductService testProductService = new ProductService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testProductService.GetProduct("5475684684"); 

            Assert.AreEqual(true, testResult);
        } 

        [TestMethod]
        public void ProductService_GetProduct_ProductIsNull()
        {
            ProductService testProductService = new ProductService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testProductService.GetProduct(string.Empty); 

            Assert.AreEqual(false, testResult);
        }
    }
} 

這是單元測試類，沒有什麼特別的，跟之前的OrderService一樣的邏輯；是不是發現兩個測試類都在公用一組相關的介面，這裡就需要我們將他們提取出來放入基類中；

using NSubstitute; 

namespace UnitTestRefactoring.UnitTests
{
    public abstract class ServiceBaseUnitTestClass
    {
        protected IServiceConnection mockServiceConnection = Substitute.For<IServiceConnection>();
        protected IServiceReader mockServiceReader = Substitute.For<IServiceReader>();
        protected IServiceWriter mockServiceWriter = Substitute.For<IServiceWriter>();
    }
} 

提取出來的測試基類；

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace UnitTestRefactoring.UnitTests
{
    [TestClass]
    public class ProductService_UnitTests : ServiceBaseUnitTestClass
    {
        [TestMethod]
        public void ProductService_GetProduct_NormalFlows()
        {
            ProductService testProductService = new ProductService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testProductService.GetProduct("5475684684"); 

            Assert.AreEqual(true, testResult);
        } 

        [TestMethod]
        public void ProductService_GetProduct_ProductIsNull()
        {
            ProductService testProductService = new ProductService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testProductService.GetProduct(string.Empty); 

            Assert.AreEqual(false, testResult);
        }
    }
} 

ProductService_UnitTests類；

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace UnitTestRefactoring.UnitTests
{
    [TestClass]
    public class OrderService_UnitTests : ServiceBaseUnitTestClass
    {
        [TestMethod]
        public void OrderService_GetOrders_NormalFlows()
        {
            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders("10293884"); 

            Assert.AreEqual(true, testResult);
        } 

        [TestMethod]
        public void OrderService_GetOrders_OrderIdIsNull()
        {
            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders(string.Empty); 

            Assert.AreEqual(false, testResult);
        }
    }
} 

OrderService_UnitTests 類；

提取出來的抽象基類能在後面的單元測試重構中幫很大忙，也是為了後面的面向特定領域的單元測試框架做要基礎工作；由於不同的單元測試類具有不同的基類，這裡需要我們自己的分析抽象，比如這裡跟Service相關的，可能還有跟Order處理流程相關的，相同的一組介面也只能出現在相關的測試類中；

2.1.2】公用的Mock行為

前面2.1.1】小結，我們講了Mock介面物件的重構，這一節我們將來分析一下關於Mock物件行為的重構；在上面的IServiceConnection中我們加入了一個Open方法，用來開啟遠端連結；

/*==============================================================================
* Author:深度訓練
* Create time: 2013-10-06
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定領域軟體工程實踐；
* ==============================================================================*/ 

namespace UnitTestRefactoring
{
    public interface IServiceConnection
    {
        bool Open();
    }
} 

如果返回true表示遠端連結成功建立並且已經成功開啟，如果返回false表示連結失敗；那麼在每一個用例程式碼中，只要使用到了IServiceConnection介面都會需要Mock介面的Open方法；

[TestMethod]
        public void OrderService_GetOrders_NormalFlows()
        {
            mockServiceConnection.Open().Returns(true);
            mockServiceConnection.Close().Returns(true); 

            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders("10293884"); 

            Assert.AreEqual(true, testResult);
        } 

        [TestMethod]
        public void OrderService_GetOrders_OrderIdIsNull()
        {
            mockServiceConnection.Open().Returns(true);
            mockServiceConnection.Close().Returns(false); 

            OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter);
            bool testResult = testOrderService.GetOrders(string.Empty); 

            Assert.AreEqual(false, testResult);
        } 

類似這樣的程式碼會很多，如果這個時候我們需要每次都在用例中對三個介面都進行類似的重複程式碼也算是一種地效率的重複勞動，並且在後面的改動中會很費事；所以這個時候抽象出來的基類就派上用場了，我們可以將構建介面的邏輯程式碼放入基類中進行統一構造；

public abstract class ServiceBaseUnitTestClass
{
    protected IServiceConnection mockServiceConnection = Substitute.For<IServiceConnection>();
    protected IServiceReader mockServiceReader = Substitute.For<IServiceReader>();
    protected IServiceWriter mockServiceWriter = Substitute.For<IServiceWriter>(); 

    protected void InitMockServiceConnection()
    {
        this.mockServiceConnection.Open().Returns(true);
        this.mockServiceConnection.Close().Returns(true);
    }
} 

this.InitMockServiceConnection();
OrderService testOrderService = new OrderService(mockServiceConnection, mockServiceReader, mockServiceWriter); 

這樣在需要修改介面的時候很容易找到，可能這裡兩三個用例，而且用例程式碼也很簡單所以看起來沒有太多的必要，但是實際情況沒有這麼簡單；

2.1.3】公用的Mock資料

說到Mock資料，其實需要解釋一下，準確點講是Mock時需要用到的測試資料，它是碎片化的簡單的測試資料；它也同樣存在著和2.1.2】小結的修改問題，實踐告訴我單元測試程式碼在整個開發週期中最易被修改，當我們簡單的修改一個邏輯之後就需要面臨著大面積的單元測試程式碼修改而測試資料修改佔比重最大；

因為測試資料相對沒有靈活性，但是測試資料的結構易發生由需求帶來的變化；比如實體的屬性型別，在我們編寫實體測試資料的時候我們用的是String，一段時間過後，實體發生變化很正常；領域模型在開發週期中被修改的次數那是無法估計，因為我們的專案中是需要迭代重構的，我們需要重構來為我們的專案保證最高的質量；

所以單元測試修改的次數和重構的次數應該是成1：0的這樣的比例，修改的範圍那就不是1：10了，有時候甚至是幾何的倍數；

OrderService中的AddOrder方法：

public bool AddOrder(Order order)
       {
           if (string.IsNullOrWhiteSpace(order.OrderId))
               return false;
           return true;
       } 

OrderService_AddOrder測試程式碼：

[TestMethod]
       public void OrderService_AddOrder_NormalFlows()
       {
           this.InitMockServiceConnection();
           OrderService testOrderService = new OrderService(this.mockServiceConnection, this.mockServiceReader, this.mockServiceWriter); 

           Order testOrder = new Order() { OrderId = "123456", SubmitDT = DateTime.Now }; 

           bool testResult = testOrderService.AddOrder(testOrder); 

           Assert.AreEqual(true, testResult);
       } 

       [TestMethod]
       public void OrderService_AddOrder_OrderIdIsNull()
       {
           this.InitMockServiceConnection();
           OrderService testOrderService = new OrderService(this.mockServiceConnection, this.mockServiceReader, this.mockServiceWriter); 

           Order testOrder = new Order() { OrderId = string.Empty, SubmitDT = DateTime.Now }; 

           bool testResult = testOrderService.AddOrder(testOrder); 

           Assert.AreEqual(false, testResult);
       } 

這是兩個用例，用來對AddOrder方法進行測試，裡面都包含了一條Order testOrder = new Order() 這樣的測試資料的構造；Order實體是一個比較簡單的物件，屬性也就只有兩個，但是真實環境中不會這麼簡單，會有幾十個欄位都需要進行測試驗證，再加上N多個用例，會使相同的程式碼變的很多；

那麼我們同樣需要將這部分的程式碼提取出來放到基類中去，適當的留有空間讓用例中修改的特殊的欄位；

完整的實體構造：

Order testOrder = this.InitNormalOrder(); 

測試OrderId為空的邏輯，需要手動設定為String.Empty：

Order testOrder = this.InitNormalOrder();
testOrder.OrderId = string.Empty; 

這樣慢慢的就會形成抗變化的測試程式碼結構，儘管一開始很彆扭，將一些直觀的物件提取出來放入一眼看不見的地方是有點不太舒服，但是長遠看來值得這麼做；

3】LINQ表示式的重構寫法（將必要的LINQ寫成普通的Function穿插在LINQ表示式中）

在使用LINQ語法編寫程式碼的時候，現在發現最大的問題就是單元測試不太方便，LINQ寫起來很方便，確實是個很不錯的程式設計思想，在面對集合型別的操作時確實是無法形容的優雅，但是面對單元測試的問題需要解決才行，所以需要我們平衡一下在什麼情況下需要將LINQ表示式替換成普通的Function來支援；

LINQ在面對集合型別的時候，能發揮很大的作用；不僅在Linq to Object中，在其他的Linq to Provider中都能在LINQ中找到了合適的使用之地；比如在對遠端Service進行LINQ設計的時候，我們都是按照這樣的方式進行編寫，但是就怕LINQ中帶有邏輯判斷的表示式，這個時候就會在單元測試中總是無法覆蓋到的情況出現，所以就需要將它提取出來使用普通的函式進行替代；

我們來繼續看一下如果使用提取出來的函式解決鏈式的判斷，還是使用上面的OrderService為例：

public Order SelectByOrderId(string orderId)
{
    List<Order> orders = new List<Order>()
    {
         new Order(){ OrderId="123", SubmitDT=DateTime.Now.AddDays(1)},
         new Order(){ OrderId="234"}
    }; 

    var list = orders.Where(order => order.OrderId == orderId && order.SubmitDT > DateTime.Now);
    if (list.Count() > 0)
        return list.ToList()[0];
    return null;
}

這是一個根據OrderId獲取Order例項的方法，純粹為了演示；首先構造了一個測試集合，然後使用了Where擴充套件方法來選擇集合中滿足條件的Order；我們的重點是Where中的條件，條件的第一個表示式很簡單而第二個表示式是SubmitDT必須大於當前的日期，還會有很多類似這樣的判斷，這樣測試起來很困難，而且很難維護，所以我們有必要將他們提取出來；

public Order SelectByOrderId(string orderId)
{
    List<Order> orders = new List<Order>()
    {
         new Order(){ OrderId="123", SubmitDT=DateTime.Now.AddDays(1)},
         new Order(){ OrderId="234"}
    }; 

    var list = orders.Where(order => IfOrderSubmitAndOrderId(order, orderId));
    if (list.Count() > 0)
        return list.ToList()[0];
    return null;
} 

private bool IfOrderSubmitDt(Order order)
{
    return order.SubmitDT > DateTime.Now;
}
private bool IfOrderSubmitAndOrderId(Order order, string orderId)
{
    return order.OrderId == orderId && this.IfOrderSubmitDt(order);
}

其實這很像企業架構模式中的規約模式，將規則物件化後就能隨便的控制他們，當然這裡是提取出方法，如果是大型企業級專案對這些易變化的點是需要抽取出來的；

總之遇到這樣的情況就使用簡單的提取方法的方式將複雜的邏輯提取出來，這也是《重構》中的重構策略的首要的模式；

4.面向特定領域的單元測試框架（一切原則即是領域驅動）

領域驅動設計已經不是什麼新鮮的話題了，它已經被我們或多或少的使用過，它強調一切從領域出發；那麼特定領域單元測試框架是一個什麼樣的框架呢，需要的價值在哪裡；其實從特定領域開發框架，特定領域架構我們能簡單的體會到一絲意思，面向特定領域單元測試框架是在單元測試框架的基礎之上進行二次領域相關的封裝；比如：如何很好的將領域規則獨立起來，如果在單元測試中使用這些獨立起來的領域規則；

其實在軟體開發的任何一個角落都能找到領域驅動的影子，這也是為什麼領域驅動會得到我們認可的重要因素；如果一切都圍繞著領域模型來的話，那麼任何一個概念都不會牽強的，我們只有關注領域本身才能使軟體真的很有價值，而不是一堆程式碼；

下面我們來簡單的看一下 面向特定領域測試框架 的兩個基本功能：

4.1.分散測試邏輯、日誌記錄（讓測試邏輯可以重組，記錄形式為領域模型）

測試程式碼執行到最後是需要對其執行的結果進行斷言的，如：Assert.IsTrue(testResult.SubmitDT > DateTime.Now);像這樣的一段程式碼我們可以適當的包裝Assert.IsTrue方法，讓他在驗證這段邏輯的時候能識別出領域概念，比如：“Order的提交時間大於今天的時間”，我們可以從兩方面入手，一個是領域的抽象，一個是規則的分解；

如果這裡的驗證不通過，我們實時的記錄領域的概念到日誌系統，而不是報告那裡程式碼出問題，這樣就算不是自己寫的程式碼都能一目瞭然；

4.2.測試用例的資料重用（為自動化測試準備固定資料，建立Assert的比較測試資料）

同樣比較重要的領域概念就是領域資料，領域資料也是單元測試中用例資料；為了能讓測試進行自動化測試，我們需要維護一組相對固定的測試資料來供測試程式執行；其實如果想最大化建立領域測試框架有必要開發一套專門的領域測試工具，它能夠實時的讀取真實資料進行Assert，也就更加的接近自動化測試；

但是單元測試也不需要對真實資料進行驗證，真實資料一般是整合測試的時候使用的，如果能用真實資料進行邏輯測試還是很有保障的；

 

作者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。