Visual Studio 中单元测试的组织
我目前正在为项目中的每个程序集创建配对的单元测试程序集，两者都位于同一文件夹中。
- MyProject/MyProject.csproj
- MyProject.Test/MyProject.Test.csproj
在查看开源项目时，我看到一些较小的项目将所有测试放在一个程序集中，而其他项目则像我一样将其分开。 我正在处理一个大型解决方案，因此将所有测试放在一个项目中是非常疯狂的。
我目前有 msbuild 逻辑来对所有 *.Test.csproj 文件运行测试。 如果我将所有测试都放在不同的文件夹中，我就不需要这样做。
只是想知道是否有任何好的论据可以以某种方式做事。
谢谢
I'm currently creating a paired unit test assembly for every assembly in my project, both are in the same folder.
- MyProject/MyProject.csproj
- MyProject.Test/MyProject.Test.csproj
Looking at open source projects, I've seen some smaller project put all tests in one assembly, and other split it out like mine. I'm dealing with a large solution so it would be pretty crazy to put all tests in one project.
I currently have msbuild logic to run tests on all *.Test.csproj files. If I had all my tests in a different folder I wouldn't need to do this.
Just wondering if there are any good arguments to do things a certain way.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我以同样的方式执行此操作，但是我更改了每个测试项目的默认命名空间以匹配生产项目的命名空间。 因此，类
XYFoo的测试位于XYFooTest中，而不是XYTest.FooTest- 这意味着您需要更少的 using 指令，并且通常会使事情变得更简单。我希望将这两个项目保留在单独的项目中的主要原因是避免将测试包含在生产库中或必须发布未经测试的库。 通过单独的项目结构，您可以针对您构建的任何内容运行单元测试。 它还可以更轻松地仅查看生产类，而无需查看两倍的文件（当获得库的“感觉”时）。
最后，不要忘记，如果您在测试时需要访问
内部成员，总有[InternalsVisibleTo]。I do it the same way but I change the default namespace for each test project to match the namespace of the production project. So the tests for class
X.Y.Fooare inX.Y.FooTestrather thanX.Y.Test.FooTest- it means you need fewer using directives, and generally makes things simpler.My main reason for wanting to keep the two in separate projects is to avoid either including the tests in the production library or having to ship an untested library. With the separate project structure, you can run unit tests against anything you build. It also makes it easier to look through just the production classes without having twice as many files to look at (when getting the "feel" of a library).
Finally, don't forget that if you need to access
internalmembers when testing, there's always[InternalsVisibleTo].我建议尽可能少地进行单元测试项目。 原因是您创建的每一个都会增加至少十秒的编译时间。 在一个大项目中，它开始增加。
这是我使用的目录结构：
projectName/branches/trunk/projects/code/codeproject1
项目名称/分支/主干/项目/代码/codeproject2
项目名称/分支/主干/项目/代码/codeproject3
项目名称/分支/主干/项目/测试/testproject1
项目名称/分支/主干/依赖项
项目名称/原型
projectName/...
以及 testproject1 中的以下目录结构：
codeproject1/
代码项目2/
代码项目2/web
代码项目2/web/mvc
代码项目3/
代码项目3/支持
I suggest making as few unit test projects as possible. The reason being is that each one you create adds on at least ten seconds of compile time. In a big project, it starts adding up.
Here's the directory structure I use:
projectName/branches/trunk/projects/code/codeproject1
projectName/branches/trunk/projects/code/codeproject2
projectName/branches/trunk/projects/code/codeproject3
projectName/branches/trunk/projects/Tests/testproject1
projectName/branches/trunk/Dependencies
projectName/prototypes
projectName/...
and within testproject1, the following directory structure:
codeproject1/
codeproject2/
codeproject2/web
codeproject2/web/mvc
codeproject3/
codeproject3/support
我做了同样的事情，除了每个项目都位于同一根文件夹下的自己的文件夹中。
以下内容：
解决方案文件夹
I do the same thing except each project is in it's own folder under the same root folder.
Something along the following:
Solution Folder
我总是为每个项目都有一个单独的测试项目。 部分原因只是我喜欢它的组织，但我也经常遇到这样的情况：我决定将一个库分解成它自己的解决方案，以便它可以被其他解决方案重用。 在这些情况下，让库项目拥有自己单独的测试项目（而不是单个项目中的所有测试）可以更轻松地分解该库。
I always have a separate test project for each project. Part of it is simply I like the organization of it, but I've also often run into situations where I've decide to break a library out into it's own solution so that it can be reused by other solutions. In those cases, having the library project have it's own separate test project (rather than all the tests in a single project) makes it much easier to break that library out.