通過命令行方式使用NUnit進行UT

極限編程(XP)越來越進入程序員的眼球，TDD(Test Drived Design)也越來越普及，UT(Unit Testing)是TDD的第一步，主要面向的是一線的開發人員，而不是項目經理、系統設計與分析人員甚至是測試人員，當然UT的一些方法也可以用于后續的測試，但從概念上來講那已經不算UT了。UT是“開發者寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確”。xUnit系列是專門用戶UT的框架（工具），包含了對目標代碼進行UT的類庫。NUnit是xUnit系列成員之一，用于對.NET Framework下的語言(實際上只要符合CTS規范的語言NUnit都支持)所寫的代碼進行UT。

UT的主要目的是提高代碼的健壯性和提高代碼的生產效率，NUnit就是以此為初衷進行設計的，所以對于使用VS.NET IDE開發而言，添加一下nunit.framework.dll的引用就可以直接在工程中進行單元測試，引用細節由IDE本身來執行，對程序員來講是透明的。如果沒有使用VS.NET等大型IDE的，比如使用編輯器+SDK+命令行的方式進行編碼，或者干脆就使用Emacs，這時很多事情就要手動進行了，這一過程可能有些boring，這也是沒辦法的事情，因為編輯器+命令行本來生產力就不高，但確是學習的好方式(也是我喜歡的方式)。這里，如果被測試代碼和測試代碼寫在不用的源文件里，進行一次UT典型步驟如下(以C#為例并假設兩個文件分別為target.cs和test.cs)：

        ·編譯被測試代碼為DLL或者Module:
            csc /t:library target.cs 或者 csc /t:module target.cs
        ·編譯測試文件為DLL，并添加對外部庫文件nunit.framework.dll和target.dll的引用：
            csc /t:library /r:c:\progra~1\nunit2~1.2\bin\nunit.framework.dll;target.dll test.cs
            或者只添加對外部庫文件nunit.framework.dll的引用并添加target模塊：
            csc /t:library /r:c:\progra~1\nunit2~1.2\bin\nunit.framework.dll /addmodule:target.netmodule test.cs
        ·NUnit命令行：
            nunit-console test.dll
            或者運行NUnit GUI打開test.dll，進行測試，生成測試報告。

這里假設NUnit安裝在c:\program files\nunit 2.2\目錄下，并且在命令行中要使用8.3格式的文件目錄名，因為csc使用過空格來區分不同編譯參數的。并且，對nunit.framework.dll的引用是必須的，不然在測試代碼中，聲明 using NUnit.Framework 會報“error CS0246: The type or namespace name @#NUnit@# could not be found (are you missing a using directive or an assembly reference?)”的錯誤。

上述過程有點繁瑣，尤其如果代碼比較多的時候，每次更改都要進行單元測試時都要進行這幾步。把這一過程寫成一個批處理，然后每次執行這個bat文件，可以緩解一點，只是文件不同時要改寫這個批處理。

雖然把不同的類(被測試類和測試類)寫在不用源文件里是程序開發的通行的方式，但對于個人學習而言把被測試類和測試類寫在一個文件里，再運用一下編輯器(我用的Ultraedit)用戶命令行工具，可以很大程度上簡化上述的編譯環節，下面以Ultraedit為例來說明一下：類設計完以后，把所有的被測試類和測試類都放在同一個文件里(為使代碼脈絡清晰，可以在不用類代碼之間加插入一個分頁符，這并不影響編譯)，然后點擊菜單“高級-〉工具欄配置”在命令行里輸入：

          csc /t:library /r:c:\progra~1\nunit2~1.2\bin\nunit.framework.dll %n%e

工作目錄里輸入：%p，再分別選中“保存活動文件”“輸出到列表窗口”“捕捉輸出”；然后再以同樣的方式新建一個用戶工具，其他參數都一樣，只是命令行改成：

          nunit-console %n.dll

這兩個工具可分別命名為：C#NUnit聯合編譯，NUnit命令行。這時高級菜單下已經多了這兩個命令，并分別有了默認的快捷鍵。ok，下面先后點擊這兩個命令，就能完成簡單的單元測試了。下面是一段簡單的源程序：

using NUnit.Framework;
using System;

// Class to be tested.
public class Target
{
    public int add(int i, int j)
    {
        return i+j;
    }
}

// Class to perform testing.
[TestFixture]
public class Test
{
    [Test]
    public void TestAdd()
    {
         Target testObj = new Target();
         Assert.AreEqual(1, testObj.add(0, 1));
         Assert.AreEqual(10, testObj.add(2, 7)); 
         Assert.AreEqual(10, testObj.add(2, 8));
         Assert.AreEqual(20, testObj.add(18, 3));
    }
}

先后點擊那兩個命令后，NUnit將檢測出第二斷言的失敗。

綜合上述簡單介紹了手動進行單元測試的方法，按照這種方式同樣可以添加nunit.core.dll的引用，來進行一些復雜的單元測試。還是那句話，對于自己的學習而言，編輯器+SDK+命令行是很好的寫代碼方式，能幫助了解文件之間、配件(Assembly)之間等的關系，還有助于記憶類的體系結構和準確的方法屬性名，可畢竟不適于工業化生產。在用了一段時間IDE之后，回歸到樸素，更能體會到編程的樂趣。這讓我想起了那句話，怎么說來著：使用Emacs是程序員追求的一種精神 :-)



Reference:
Andrew Hunt, David Thomas, 單元測試之道C#版；http://www.nunit.org/csc.exe -hhttp://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/
Roadahead, 0503, 于宿舍

原文轉自：http://www.kjueaiud.com