Luk*_*kas 15 .net unit-testing
我有大约270个项目的解决方案,它包含各种文件夹等.想象一下每个项目都有单元测试,你认为什么是组织它们的最佳方法？每个项目是否应该附近有单元测试,或者我应该为它们创建特殊文件夹,甚至是单独测试的不同解决方案.
你如何组织这些大型解决方案/项目？
Jon*_*eet 16
具有270个项目的单一解决方案听起来像是一个问题.打开VS需要多长时间？:)(严重的是,您可以将一些项目组合在一起还是拆分解决方案？)
通常我会将单元测试保留在他们自己的项目中,但是在同一个解决方案中.在项目中,镜像生产项目的文件夹/命名空间结构.看看Noda Time如何组织起来作为一个例子.我一直在那些他们被保存在一个单独的解决方案中的公司,但这真的很痛苦.(他们有一个很好的理由:测试是在VS2005中,生产代码是2003年.)
有时我将测试项目的默认命名空间设置为与生产项目相同 - 这在Java中比在.NET中更重要(因为它可以让您获得包访问成员)但它仍然有用,因为它意味着您要测试的类不需要导入.
Mar*_*ann 16
每个目标项目应该有一个(或多个)单元测试项目.这是您保持灵活性并使每个单元测试套件与目标项目一起变化的唯一方法.
如果您有一个单元测试项目涉及多个目标项目,则会在这两个项目之间创建一个人工紧密耦合,因为如果没有所有目标项目,您将无法编译单元测试项目.这再次使得单独测试单个项目变得非常困难 - 这就是单元测试的全部内容.
如果需要在多个测试目标之间共享测试代码,则可以始终使用通用的可重用测试API创建共享库,只要它不引用任何目标项目即可.
也就是说,我必须同意Jon Skeet的观点,即270个项目的解决方案是必须首先解决的结构气味(除非它是用于自动构建的"全部构建"解决方案).
| 归档时间： |
|
| 查看次数： |
7575 次 |
| 最近记录： |