Pat*_*key 5 c# unit-testing visual-studio
在JavaLand中,我习惯于创建包含生产和测试代码的项目.我喜欢这种做法,因为它简化了内部代码的测试,而没有人为地暴露项目发布的API中的内部.
到目前为止,根据我使用C#/ Visual Studio/ReSharper/NUnit的经验,我为生产和测试代码创建了单独的项目(即单独的DLL).这是成语,还是我不在基地?如果这个惯用正确,那么处理为测试目的公开类和方法的正确方法是什么?
谢谢,
-Patrick
测试内部代码很简单:用于[InternalsVisibleTo]使您的生产装配"信任"您的测试装配.然后,测试组件可以访问所有生产组件的内部成员.
上面链接的MSDN文档给出了一个示例.这很简单.
IMO,你绝对应该把你们两个分开.您并不希望您的测试代码(或数据)最终出现在生产程序集中.
编辑:只是回应史蒂文关于测试内部结构的观点:我认为测试内部结构是完全合理的.我将单元测试视为白盒测试,而不是黑盒测试.肯定有一个地方只测试公共API - 尤其是集成测试 - 但我发现有很多地方测试内部成员是有意义的.哎呀,没有那种能力,你打算怎么测试内部类型?有时,相对较小的公共API在复杂的内部实现之上进行分层 - 并且该实现的测试单元可能仅通过公共API而变得棘手.
它确实使测试更加脆弱,因为内部实现更改可能需要测试更改,如果您只测试公共API则不需要测试更改...但它也可以使生产代码更加健壮,因为您更多可能会为角落案例等编写大量测试,如果这样做很容易的话.
在所有事情上都适度,基本上.
| 归档时间: |
|
| 查看次数: |
770 次 |
| 最近记录: |