在看了博客园前面的一些文章,如: "在单元测试中,如何测试非Public对象" ,"增强NUnit单元测试功能" 和"也谈在NUnit中测试私有成员" 以及 相关评论(以及"VSNUnit2k3 .NUnit在VS.NET 2003上的插件"的评论)...
感觉有些话想说出来,不吐不快..
1,应不应该由工具自动为我们生成TestCase?
TDD中所要求的写TestCase,正是要求程序员(此程序的开发者)站在使用者的角度,来思考需要暴露哪些接口,这些接口需要什么样的参数?
正如Hush所说的,"首先，NUnit这样的工具应该用来对外部接口进行测试，尤其在测试驱动开发里，你写下test case的时候，实际上是迫使你站到了用户的立场上，写下一个test case，其实也就是写下了一个use case，这使你对要开发的程序有更深一层次的理解，而用户显然是不应该知道私有成员这些实现细节的，如果你也测试私有成员的话就会破坏单元测试的这种功效。"
所以,TestCase是不应该由工具来自动生成的.必须是由程序员自己实现的.
2,应不应该测试非Public成员?
从TDD一书我们可以了解到,TestCase是用来测试已被暴露的接口的.即是Public成员.由于写TestCase时是站在使用者的角度,所以是不应该知道类的内部实现细节的,它只是仅仅要求了解公开的接口.所以,从TDD的观点来看是不应该测试非Public成员的.
由于Test的本意是用来检查程序的功能是否是我们所希望的,换句话说就是看程序运行有没有错误.在TDD出现以前,我们都是使用断点Debug来查错的.现在有了TDD,我们可以写完一个小功能模块或是一个函数就可以进行测试.比先写一大堆,再一个个用Debug进行检测/队错方便多了.但是由于一些特殊情况,如一个Dll Library,它是不能够直接进行Debug的(对不对?),这个时候我们如果不得不检查一个公用接口中调用的若干非Public成员就很不方便(不能Debug嘛)..这个时候那我们就可以尝试使用Reflection对非Public成员进行测试..
所以我觉得在一般的情况下,建议不要对非Public成员进行测试.只有在没有调试器的时候才偶尔对非Public成员进行测试.(如果不是这种情况,那很可能你的程序设计的有问题
)
中国一句古话: 兵马未动,粮草先行,用在TDD中就是: 代码未写,测试先行...
感觉有些话想说出来,不吐不快..
1,应不应该由工具自动为我们生成TestCase?
TDD中所要求的写TestCase,正是要求程序员(此程序的开发者)站在使用者的角度,来思考需要暴露哪些接口,这些接口需要什么样的参数?
正如Hush所说的,"首先，NUnit这样的工具应该用来对外部接口进行测试，尤其在测试驱动开发里，你写下test case的时候，实际上是迫使你站到了用户的立场上，写下一个test case，其实也就是写下了一个use case，这使你对要开发的程序有更深一层次的理解，而用户显然是不应该知道私有成员这些实现细节的，如果你也测试私有成员的话就会破坏单元测试的这种功效。"
所以,TestCase是不应该由工具来自动生成的.必须是由程序员自己实现的.
2,应不应该测试非Public成员?
从TDD一书我们可以了解到,TestCase是用来测试已被暴露的接口的.即是Public成员.由于写TestCase时是站在使用者的角度,所以是不应该知道类的内部实现细节的,它只是仅仅要求了解公开的接口.所以,从TDD的观点来看是不应该测试非Public成员的.
由于Test的本意是用来检查程序的功能是否是我们所希望的,换句话说就是看程序运行有没有错误.在TDD出现以前,我们都是使用断点Debug来查错的.现在有了TDD,我们可以写完一个小功能模块或是一个函数就可以进行测试.比先写一大堆,再一个个用Debug进行检测/队错方便多了.但是由于一些特殊情况,如一个Dll Library,它是不能够直接进行Debug的(对不对?),这个时候我们如果不得不检查一个公用接口中调用的若干非Public成员就很不方便(不能Debug嘛)..这个时候那我们就可以尝试使用Reflection对非Public成员进行测试..
所以我觉得在一般的情况下,建议不要对非Public成员进行测试.只有在没有调试器的时候才偶尔对非Public成员进行测试.(如果不是这种情况,那很可能你的程序设计的有问题
)中国一句古话: 兵马未动,粮草先行,用在TDD中就是: 代码未写,测试先行...
