極限編程(xp)越來越進(jìn)入程序員的眼球，tdd(test drived design)也越來越普及，ut(unit testing)是tdd的第一步，主要面向的是一線的開發(fā)人員，而不是項目經(jīng)理、系統(tǒng)設(shè)計與分析人員甚至是測試人員，當(dāng)然ut的一些方法也可以用于后續(xù)的測試，但從概念上來講那已經(jīng)不算ut了。ut是“開發(fā)者寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確”。xunit系列是專門用戶ut的框架（工具），包含了對目標(biāo)代碼進(jìn)行ut的類庫。nunit是xunit系列成員之一，用于對.net framework下的語言(實際上只要符合cts規(guī)范的語言nunit都支持)所寫的代碼進(jìn)行ut。

ut的主要目的是提高代碼的健壯性和提高代碼的生產(chǎn)效率，nunit是以此為初衷進(jìn)行設(shè)計的，所以對于使用vs.net ide開發(fā)而言，添加一下nunit.framework.dll的引用可以直接在工程中進(jìn)行單元測試，引用細(xì)節(jié)由ide本身來執(zhí)行，對程序員來講是透明的。如果沒有使用vs.net等大型ide的，比如使用編輯器+sdk+命令行的方式進(jìn)行編碼，或者干脆使用emacs，這時很多事情要手動進(jìn)行了，這一過程可能有些boring，這也是沒辦法的事情，因為編輯器+命令行本來生產(chǎn)力不高，但確是學(xué)習(xí)的好方式(也是我喜歡的方式)。這里，如果被測試代碼和測試代碼寫在不用的源文件里，進(jìn)行一次ut典型步驟如下(以c#為例并假設(shè)兩個文件分別為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 unit2~1.2in unit.framework.dll;target.dll test.cs
            或者只添加對外部庫文件nunit.framework.dll的引用并添加target模塊：
            csc /t:library /r:c:progra~1 unit2~1.2in unit.framework.dll /addmodule:target.netmodule test.cs
        ·nunit命令行：
            nunit-console test.dll
            或者運行nunit gui打開test.dll，進(jìn)行測試，生成測試報告。

這里假設(shè)nunit安裝在c:program files unit 2.2目錄下，并且在命令行中要使用8.3格式的文件目錄名，因為csc使用過空格來區(qū)分不同編譯參數(shù)的。并且，對 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?)”的錯誤。

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

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

          csc /t:library /r:c:progra~1 unit2~1.2in unit.framework.dll %n%e

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

          nunit-console %n.dll

這兩個工具可分別命名為：c#nunit聯(lián)合編譯，nunit命令行。這時高級菜單下已經(jīng)多了這兩個命令，并分別有了默認(rèn)的快捷鍵。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將檢測出第二斷言的失敗。

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