最佳实践:组织单元测试

时间:2009-11-25 07:01:16

标签: .net unit-testing

我有> 270个项目的解决方案,它包含各种文件夹等。想象一下每个项目都有单元测试,您认为组织它们的最佳方法是什么?每个项目是否应该附近有单元测试,或者我应该为它们创建特殊文件夹,甚至是单独测试的不同解决方案。

如何组织这些大型解决方案/项目?

3 个答案:

答案 0 :(得分:16)

一个包含270个项目的解决方案听起来像是一个问题。打开VS需要多长时间? :)(严重的是,您可以将一些项目组合在一起还是拆分解决方案?)

通常我将单元测试保留在他们自己的项目中,但是在同一个解决方案中。在项目中,镜像生产项目的文件夹/命名空间结构。看看Noda Time如何组织一个例子。我一直在那些他们被保存在一个单独的解决方案中的公司,但这真的很痛苦。 (他们有一个很好的理由:测试是在VS2005中,生产代码是2003年。)

有时我将测试项目的默认命名空间设置为与生产项目相同 - 这在Java中比在.NET中更重要(因为它可以让您获得包访问成员)但它仍然可以提供帮助因为这意味着您要测试的课程不需要导入。

答案 1 :(得分:16)

每个目标项目应该有一个(或多个)单元测试项目。这是您保持灵活性并将每个单元测试套件与目标项目一起改变的唯一方法。

如果您有一个单元测试项目涉及多个目标项目,这将在这两个项目之间创建一个人工紧耦合,因为如果没有全部项目,您将无法编译单元测试项目它的目标项目。这再次使得单独测试单个项目变得非常困难 - 这就是单元测试的全部内容。

如果您需要在多个测试目标之间共享测试代码,您始终可以使用通用的可重用测试API创建共享库,只要它不引用任何目标项目。

那就是说,我必须同意Jon Skeet的观点,即270个项目的解决方案是必须首先解决的结构气味(除非它是用于自动构建的“全部构建”解决方案)。

答案 2 :(得分:0)

从内置的Visual Studio测试框架切换到Gallio后,我开始将我的测试放在同一项目中的Test文件夹中。对于小助手类,我甚至可以在同一文件夹中定义单元测试。只要您的命名空间相对较小(我不喜欢拥有庞大的命名空间文件夹),这对我来说不会增加太多的混乱。无论如何,稍后,当这些类已经存在一段时间并且稳定时,您可以将这些单元测试移动到单独的文件夹中。