在阅读 Enterprise Library 代码的时候,我们可以看到 Enterprise Library 的测试代码和实现功能代码是在一个项目中的。这么做的好处在于:
测试跟实现代码放在一起,我们就可以测试 internal 的方法函数。参见对 internal 的定义:internal 关键字是类型和类型成员的访问修饰符。内部成员只有在同一程序集中的文件内才是可访问的。http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/csref/html/vclrfInternalPG.asp
测试代码和具体实现代码放在一个项目中,这时候我们就需要区分测试版和运行版,就类似于编译工程有Debug版和Release版一样。
下面我们简单的看看实现自定义区分不同的编译版本。首先我们仍然来看 Enterprise Library 的代码,在它的项目中,我们可以看到,编译一个项目的时候,有六个编译选项,而不是以前默认只有的两个编译选项,如下图: 对应的编译出来的版本,就具有或者不具有对应的某一部分功能。我们如果要作单元测试,只需要编译出对应的版本既可以,在发布的时候,发布一个Release版本,这个版本就会不包含单元测试代码。
下面我们来看 Enterprise Library 具体如何实现的。
1、首先我们来看如何实现增加这几个编译选项。
A、在“解决方案资源管理器”中选中解决方案。B、在“生成”菜单中选择“配置管理器”菜单项,这时候会有“配置管理器”窗口出来。C、打开“活动的解决方案配置”下的下拉列表框,下拉列表项中有一项“新建”,单击它。如下图: D、在“新建解决方案配置”窗体中,输入编译选项的名称,同时为了方便,选择一个跟这个编译选项配置比较接近的已有编译选项。如下图所示: E、重复C、D操作,把你准备增加的编译选项都增加上去。F、对不同的工程项目,也做类似的配置。基本类似,这里就不重复了。
2、下面我们来配置具体的编译选项。
A、选中其中一个项目,右键单击选择属性。B、在属性页左边依次选择“配置属性”,“生成”。修改这时候右边 “条件编译常数” 中的值,比如下图方式: 上图增加了 UNIT_TESTS 编译常数。这样我们在代码中只要判断有没有这个编译常数,既可以让他去做一些事情。如下述代码:
这样,就可以实现如果我们采用的是 DebugUnitTests方式编译,就可以把测试代码编译到组件中,如果我们需要发布的时候,则不需要编译这部分代码。注意:项目中别忘了引用nunit.framework.dll
我们可以使用 ilDasm 反编译生成的不同版本程序集。来证明我们上述做法是否正确。证明部分这里就不做展示了。