IDC资讯中心
极限编程(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, 于宿舍
