Sea*_*n U 6 .net c# unit-testing
我知道(并同意)将单元测试放在单独的程序集中的常用参数.但是,最近我遇到了一些我真的想要测试私有方法的情况.有问题的幕后逻辑足够复杂,以至于测试公共和内部接口并不能完成任务.对班级公共界面的测试感觉过于紧张,我看到几个地方,对私人的一些测试可以更简单有效地完成工作.
在过去,我通过制作我需要测试的东西来解决这些情况protected,并创建一个我可以用来在测试框架中获取它的子类.但是,这并不在类,应该是工作这么好sealed.更不用说用所有脚手架膨胀测试框架.
所以我正在考虑这样做:在课堂上放置一些测试,他们可以在那里找到私人成员.但是使用'#if DEBUG`将它们排除在生产代码之外.
这看起来是个好主意吗？
OP问题的解决方案是将IoC与DI正确合并,并且无需完全测试私有方法(正如Joel Martinez所说).因为它是被提到的多个 次,单元测试私有成员是不是要走的路.
但是,有时您无法更改代码(遗留系统,破坏更改的风险 - 您的名字),也无法使用允许私有成员测试的工具(如Typemock,即付费产品).对于这种情况,您可以根本不进行测试,也可以偷工减料.我相信OP的情况正面临着.
请记住,您可以使用反射来访问和调用私有成员.
在我看来,在类本身中放置条件调试是一个相当糟糕的想法 - 它会在类代码中添加噪声(如不相关的内容).当然,它将在发布时消失,但你(可能还有其他程序员)将不得不在日常基础上处理它.
我意识到你的想法在纸上听起来不错 - 用条件调试包装的简单测试.但实际上,测试很快就会变成使用额外的变量(那些也必须放在类代码中),一些实用程序(额外的引用,自定义类型),测试框架(甚至更多的引用)以及什么不是.这一切都必须以某种方式连接到类代码.把它们放在一起,你很快就会找到一个无法造意的怪物.
你确定要处理它吗？特别是考虑到将简单的基于反射的实用程序放在一起可能并不那么难.