单元测试应该在.Net解决方案中的自己的项目中

uri*_*ium 19 .net unit-testing project-structure

我应该为单元测试开始一个新项目吗?这意味着我会得到两个可执行文件正确吗?然后我担心命名空间组织.我是否可以将单元测试放在与他们正在测试的类相同的名称空间中,尽管它们是不同项目的一部分?

这提出了另一个问题.我知道命名空间命名约定是CompanyName.TechnologyName.Feautre.Design.如何在我的解决方案/项目布局中实现这一目标?解决方案名称=公司名称,项目名称=技术名称?

如果是这样的话,这意味着我无法将我的单元测试分成新项目.

Mar*_*ann 35

最好的方法是为每个"生产项目"建立一个单独的单元测试项目.这可以确保您可以成对变化并移动它们.

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

将单元测试保存在单独的库中非常重要,因为这样可以确保只测试代码的公共API(黑盒测试).

我通过在目标命名空间后附加"UnitTest"来命名我的命名空间.

  • @Arnis L.:如果您*必须*在您的解决方案中有数百个项目,那么您需要紧密耦合的代码.你的问题不在于你是否有1个或x个单元测试项目 - 你的问题是紧耦合.在这种情况下,将自己限制在单个单元测试项目中只是**处理症状**.更好的解决方案是处理根本问题. (4认同)
  • @Arnis L.:我认为关于不需要在其他地方重用部分应用程序的论点是一个自我实现的预言,因为它会导致你实现它,这确实是不可能的,即使它后来应该成为可取的.但是,如果您要使用域模型,则很可能会再次使用此部分 - 例如,作为提供原始应用程序的自动化接口的Web服务. (4认同)
  • @Arnis L.:每个解决方案的1个单元测试项目在解决方案和目标项目之间创建了一个人为的紧密耦合.想象一下,您希望在不同的解决方案中重用您的一个项目,但您仍然希望在该新解决方案中对该项目进行单元测试覆盖.这是不可能的,因为单个单元测试项目耦合了几个项目.我一直在那里遭受痛苦,我再也不想那样做了. (3认同)
  • @Arnis L:那不是我说的.想象一下,您的解决方案包含LibraryA和LibraryB(两个生产代码).如果您只有一个单元测试项目同时针对LibraryA和LibraryB,则需要从单元测试项目中引用LibraryA和LibraryB.现在,如果您想在新的解决方案中重用LibraryA(但不是LibraryB)*及其单元测试*,则不能,因为如果不存在LibraryB,单元测试将无法编译. (3认同)

Wim*_*dse 8

我倾向于每个组件都有一个特定的测试项目/ 组件.测试程序集将与它应该测试的程序集具有相同的名称,并.Test在名称和名称空间中添加.

这样,您可以将测试隔离,并且不会使用生产代码进行部署.


Arn*_*psa 5

每个解决方案的1个测试项目,其中包含folders => regression/integration/unit,其子文件夹"镜像"您的解决方案项目/文件夹架构.

记住 - 测试不是您的生产代码.他们应该分开.

  • 有趣的是,我知道有一家公司通过他们的应用程序运送测试.实际上,它们可以从应用程序中运行.对于集成测试更有意义,我想...... (2认同)