>客户端(包含视图，控制器等)
> Client.Tests
>常用(包含数据/服务合同，常用实用程序等)
> Common.Tests
>服务器(包含域，服务等)
> Server.Tests
> Server.WebHost
最近在工作中，人们一直提到只有一个单元测试项目，而不是由他们正在测试的组件打破它们。我知道回到当天，如果你正在运行NCover等作为你的构建的一部分(当然不再重要)，这使得生活更轻松。
单一与多个UnitTest项目背后的一般理性是什么？除了减少解决方案中的项目数量外，还有一个具体的理由要走一条路吗？我得到的印象可能是这些“偏好”的东西之一，但谷歌没有变得太多。
对我来说，这意味着，我想快速找到东西，我想看看什么是测试什么，我想要运行较小的东西来更好的控制，以防我想在配置文件或做其他的测试。当您调试失败的测试时，这通常很好。我不想花费额外的时间弄清楚任何事情，它应该自己说明事情是如何映射的，什么属于什么。
对我而言，另一件非常重要的事情是我想尽可能地隔离，并有明确的界限。您想要提供一种简单的方法来将您的大型项目的部分重组/移出到一个独立的项目中。
就个人而言，我总是安排我的测试，关于我的软件结构，这意味着类和它的测试，库和测试可执行文件之间的一对一映射。这为您提供了一个很好的测试结构，可以反映您的软件结构，从而提供查找内容的清晰度。此外，它提供了一个自然的分裂，以防某些东西被独立移出。
这是我尝试各种方式做事情后的个人选择。
在我看来，分组的东西，当太多不一定是一件好事。可以这样做，但是我相信在这个讨论中，单个测试项目是错误的。太多的测试项目与许多文件内部意味着只有一个与大量的测试文件。我相信真正的问题是你正在努力的解决方案越来越大。也许还有其他一些事情可以避免“一个世界”呢？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
