通过命令行方式使用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:

1. Andrew Hunt, David Thomas, 单元测试之道C#版；
2. http://www.nunit.org/
3. csc.exe -h
4. http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/

Roadahead, 0503, 于宿舍