.net – 每个解决方案的单一测试项目

我通常在我的产品组件和我的单元测试组件之间进行1:1的映射。我通常试图保持总体数量低,典型的解决方案可能看起来像…

>客户端(包含视图,控制器等)
> Client.Tests
>常用(包含数据/服务合同,常用实用程序等)
> Common.Tests
>服务器(包含域,服务等)
> Server.Tests
> Server.WebHost

最近在工作中,人们一直提到只有一个单元测试项目,而不是由他们正在测试的组件打破它们。我知道回到当天,如果你正在运行NCover等作为你的构建的一部分(当然不再重要),这使得生活更轻松。

单一与多个UnitTest项目背后的一般理性是什么?除了减少解决方案中的项目数量外,还有一个具体的理由要走一条路吗?我得到的印象可能是这些“偏好”的东西之一,但谷歌没有变得太多。

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

对我来说,这意味着,我想快速找到东西,我想看看什么是测试什么,我想要运行较小的东西来更好的控制,以防我想在配置文件或做其他的测试。当您调试失败的测试时,这通常很好。我不想花费额外的时间弄清楚任何事情,它应该自己说明事情是如何映射的,什么属于什么。

对我而言,另一件非常重要的事情是我想尽可能地隔离,并有明确的界限。您想要提供一种简单的方法来将您的大型项目的部分重组/移出到一个独立的项目中。

就个人而言,我总是安排我的测试,关于我的软件结构,这意味着类和它的测试,库和测试可执行文件间的一对一映射。这为您提供了一个很好的测试结构,可以反映您的软件结构,从而提供查找内容的清晰度。此外,它提供了一个自然的分裂,以防某些东西被独立移出。

这是我尝试各种方式做事情后的个人选择。

在我看来,分组的东西,当太多不一定是一件好事。可以这样做,但是我相信在这个讨论中,单个测试项目是错误的。太多的测试项目与许多文件内部意味着只有一个与大量的测试文件。我相信真正的问题是你正在努力的解决方案越来越大。也许还有其他一些事情可以避免“一个世界”呢?

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...