每个解决方案的单一与多单元测试项目?

Chr*_*ter 25 .net unit-testing

我的产品组件和单元测试组件之间通常有1:1的映射关系.我通常会尝试保持较低的组件总数,典型的解决方案可能看起来像...

  • 客户端(包含视图,控制器等)
  • Client.Tests
  • 通用(包含数据/服务合同,常用功能等)
  • Common.Tests
  • 服务器(包含域,服务等)
  • Server.Tests
  • Server.WebHost

最近在工作中,人们提到只有一个单元测试项目,而不是他们正在测试的程序集.我知道这一天,如果你在构建中运行NCover等(当然不再重要),这会让生活变得更轻松.

单个与多个UnitTest项目背后的一般理性是什么?除了减少解决方案中的项目数量之外,还有一个具体的理由可以采用这种方式吗?我觉得这可能是那些"偏好"的东西之一,但谷歌搜索并没有出现太多.

mur*_*att 19

没有确切的答案,因为这一切都取决于你的工作是什么,以及个人品味.但是,您肯定希望以某种方式安排事情,以便您可以有效地工作.

对我来说,这意味着,我想快速找到东西,我想看看测试什么,我想运行较小的东西以便更好地控制,以防我想要在测试中进行分析或做其他事情.当您调试失败的测试时,这通常很好.我不想花费额外的时间来解决任何事情,它应该说明事物是如何映射的以及什么属于什么.

对我来说另一个非常重要的事情是我希望尽可能地隔离并且有明确的界限.您希望提供一种简单的方法来将大项目的一部分重构/移出到一个独立的项目中.

就个人而言,我总是围绕我的软件结构安排我的测试,这意味着类与其测试,库和测试可执行文件之间的一对一映射.这为您提供了一个很好的测试结构,它反映了您的软件结构,从而为查找事物提供了清晰的依据.此外,它还可以在某些东西独立移出时提供自然分割.

在尝试各种方法后,这是我个人的选择.

在我看来,当有太多东西时将事物分组并不一定是好事.它可以,但我相信在这个讨论的背景下,它是单个测试项目的错误论据.包含许多文件的测试项目太多意味着只有一个包含大量测试文件的测试项目.我相信真正的问题是你正在努力解决的问题是变大.也许还有其他事情可以避免"一个世界"?:)


Eri*_* J. 12

除了其他(好的)答案之外,请考虑在较大的项目团队中,个别团队成员可以创建自己的解决方案,仅包括他们正在处理的项目子集.

假设一个单一的解决方案,其中一个测试项目涵盖了该解决方案中的所有内容,那么就会出现故障.


Ian*_*Ian 5

我要说的部分原因是它迫使您只招募您正在测试的程序集。所以你的单元测试不会意外地变成集成测试或更糟。它有助于确保关注点分离。