C# 你把单元测试放在同一个项目还是另一个项目中？

Do you put unit tests in same project or another project?

提问by leora

Do you put unit tests in the same project for convenience or do you put them in a separate assembly?

为了方便起见，您是将单元测试放在同一个项目中还是将它们放在单独的程序集中？

If you put them in a separate assembly like we do, we end up with a number of extra projects in the solution. It's great for unit testing while coding but how do you release the application without all of these extra assemblies?

如果您像我们一样将它们放在一个单独的程序集中，我们最终会在解决方案中产生许多额外的项目。它非常适合在编码时进行单元测试，但是如何在没有所有这些额外程序集的情况下发布应用程序？

采纳答案by Jason Hymanson

In my opinion, unit tests should be placed in a separate assembly from production code. Here are just a few cons of placing unit tests in the same assembly or assemblies as production code are:

在我看来，单元测试应该放在与生产代码不同的程序集中。以下是将单元测试放在与生产代码相同的一个或多个程序集中的几个缺点：

1. Unit tests get shipped with production code. The only thing shipped with product code is production code.
2. Assemblies will be unnecessarily bloated by unit tests.
3. Unit tests can affect build processes like automated or continuous build.

1. 单元测试随生产代码一起提供。产品代码附带的唯一内容是生产代码。
2. 单元测试会使程序集不必要地膨胀。
3. 单元测试会影响构建过程，如自动化或持续构建。

I don't really know of any pros. Having an extra project (or 10) isn't a con.

我真的不知道有什么优点。拥有一个额外的项目（或 10 个）并不是一个骗局。

Edit: More Info On Build and Shipping

编辑：有关构建和运输的更多信息

I would further recommend that any automated build process place production and unit tests into different locations. Ideally, the unit test build process only runs if the production code builds, and copies the product files into the unit tests directory. Doing it this way results in the actual bits being separated for shipping, etc. Additionally, it is fairly trivial to run automated unit testing at this point on all tests in a particular directory.

我进一步建议任何自动化构建过程将生产和单元测试放在不同的位置。理想情况下，单元测试构建过程仅在生产代码构建时运行，并将产品文件复制到单元测试目录中。这样做会导致实际的位被分离以进行运输等。此外，此时对特定目录中的所有测试运行自动化单元测试是相当简单的。

To summarize, here is the general idea for a daily build and testing and shipping of bits and other files:

总而言之，以下是比特和其他文件的日常构建、测试和传送的总体思路：

1. Production build runs, placing production files into a specific "production" directory.
   1. Build production projects only.
   2. Copy compiled bits and other files into a "production" directory.
   3. Copy bits and other files into a release candidate directory, aka a Christmas release directory would be "Release20081225".
2. If production build succeeds, unit test build runs.
   1. Copy production code to "tests" directory.
   2. Build unit tests to "tests" directory.
   3. Run unit tests.
3. Send build notifications and unit tests results to developers.
4. When a release candidate (like Release20081225) is accepted, ship these bits.

1. 生产构建运行，将生产文件放入特定的“生产”目录。
   1. 仅构建生产项目。
   2. 将编译后的位和其他文件复制到“生产”目录中。
   3. 将位和其他文件复制到发布候选目录中，也就是圣诞节发布目录将是“Release20081225”。
2. 如果生产构建成功，则运行单元测试构建。
   1. 将生产代码复制到“tests”目录。
   2. 将单元测试构建到“tests”目录。
   3. 运行单元测试。
3. 向开发人员发送构建通知和单元测试结果。
4. 当发布候选版本（如 Release20081225）被接受时，发送这些位。

回答by tvanfosson

My unit tests always go in a separate project. In fact, for every project I have in my solution, there is a separate test project that goes along with it. Testing code is not application code and should not be intermingled with it. One advantage to keeping them in separate projects -- at least using TestDriven.Net -- is that I can right-click on a test project and run all the tests in that project, testing an entire library of application code with one click.

我的单元测试总是在一个单独的项目中进行。事实上，对于我的解决方案中的每个项目，都有一个单独的测试项目与之配套。测试代码不是应用程序代码，不应与其混合。将它们保存在单独的项目中的一个优势——至少使用 TestDriven.Net——是我可以右键单击一个测试项目并运行该项目中的所有测试，一键测试整个应用程序代码库。

回答by Jon Skeet

Separate project, but in the same solution. (I've worked on products with separate solutions for test and production code - it's horrible. You're always switching between the two.)

单独的项目，但在同一个解决方案中。（我曾开发过具有单独的测试和生产代码解决方案的产品 - 这太可怕了。你总是在两者之间切换。）

The reasons for separate projects are as stated by others. Note that if you're using data-driven tests, you might end up with quite a significant amount of bloat if you include the tests in the production assembly.

单独项目的原因如其他人所述。请注意，如果您正在使用数据驱动的测试，并且在生产程序集中包含这些测试，则最终可能会出现相当大的膨胀。

If you need access to the internal members of the production code, use InternalsVisibleTo.

如果您需要访问生产代码的内部成员，请使用InternalsVisibleTo。

回答by orip

I fluctuate between same project and different projects.

我在同一个项目和不同的项目之间波动。

If you're releasing a library releasing the test code with the production code is a problem, otherwise I find it usually isn't (although there's a strong psychological barrier before you try).

如果你发布一个库，发布带有生产代码的测试代码是一个问题，否则我发现它通常不是（尽管在你尝试之前有很强的心理障碍）。

When putting tests in the same project I find it easier to switch between tests and the code they test, and easier to refactor/move them around.

当将测试放在同一个项目中时，我发现在测试和它们测试的代码之间切换更容易，并且更容易重构/移动它们。

回答by Joseph Ferris

I put them in separate projects. The name of the assembly mirrors that of the namespaces, as a general rule for us. So if there is a project called Company.Product.Feature.sln, it has an output (assembly name) of Company.Product.Feature.dll. The test project is Company.Product.Feature.Tests.sln, yielding Company.Product.Feature.Tests.dll.

我把它们放在不同的项目中。作为我们的一般规则，程序集的名称反映了命名空间的名称。因此，如果有一个名为 Company.Product.Feature.sln 的项目，它的输出（程序集名称）为 Company.Product.Feature.dll。测试项目是 Company.Product.Feature.Tests.sln，产生 Company.Product.Feature.Tests.dll。

You are best keeping them in a single solution and controlling the output via the Configuration Manager. We have a named configuration for each of the main branches (Development, Integration, Production) in lieu of using the default Debug and Release. Once you have your configurations setup, you can then include or exclude them by clicking on the "Build" checkbox in the Configuration Manager. (To get the Configuration Manager, right-click the solution and go to Configuration Manager.) Note, that I find the CM in Visual Studio to be buggy at times. A couple of times, I have had to go into the project and/or solution files to clean up the targets that it created.

您最好将它们保存在一个解决方案中，并通过配置管理器控制输出。我们为每个主要分支（开发、集成、生产）都有一个命名配置，而不是使用默认的调试和发布。完成配置设置后，您可以通过单击配置管理器中的“构建”复选框来包含或排除它们。（要获取配置管理器，请右键单击解决方案并转到配置管理器。）请注意，我发现 Visual Studio 中的 CM 有时有问题。有几次，我不得不进入项目和/或解决方案文件来清理它创建的目标。

Additionally, if you are using Team Build (and I am sure that other .NET build tools are the same) you can then associate the build with a named configuration. This means that if you don't build your unit tests for your "Production" build, for example, the build project can be aware of this setting as well and not build them since they were marked as such.

此外，如果您使用的是 Team Build（并且我确信其他 .NET 构建工具是相同的），那么您可以将构建与命名配置相关联。这意味着，例如，如果您不为“生产”构建构建单元测试，构建项目也可以知道此设置，并且不会构建它们，因为它们被标记为这样。

Also, we used to do XCopy drops off of the build machine. The script would just omit copying anything named *.Tests.Dll from being deployed. It was simple, but worked.

此外，我们过去常常从构建机器上下载 XCopy。该脚本只会省略复制任何名为 *.Tests.Dll 的内容，以免被部署。这很简单，但有效。

回答by Joseph Ferris

I do not understand the frequent objection to deploying tests with production code. I led a team at a small microcap (grew from 14 to 130 people). We had a half-dozen or so Java apps and we found it EXTREMELY valueable to deploy tests into the field to execute them on a specificmachine that was exhibiting unusual behavior. Random problems occur in the field and being able to throw a few thousand unit tests at the mystery with zero cost was invaluable and often diagnosed problems in minutes...including installation problems, flaky RAM problems, machine-specific problems, flaky network problems, etc, etc. I think it is incredibly valuable to put tests into the field. Also, random problems pop up at random times and it is nice to have the unit tests sitting there already waiting to be executed at a moments notice. Hard-drive space is cheap. Just like we try to keep data and functions together (OO design), I think there is something fundamentally valuable in keeping code and tests together (function + tests that validate the functions).

我不明白人们经常反对使用生产代码部署测试。我领导的团队规模很小（从 14 人增加到 130 人）。我们有六个左右的 Java 应用程序，我们发现将测试部署到现场以在特定的环境中执行它们非常有价值表现出异常行为的机器。现场随机出现的问题，能够以零成本对这个谜团进行几千个单元测试是非常宝贵的，而且经常在几分钟内诊断出问题……包括安装问题、不稳定的 RAM 问题、特定于机器的问题、不稳定的网络问题，等等等等。我认为在现场进行测试是非常有价值的。此外，随机问题会在随机时间出现，让单元测试坐在那里等待立即执行是很好的。硬盘空间很便宜。就像我们试图将数据和功能放在一起（OO 设计），我认为将代码和测试放在一起（功能 + 验证功能的测试）具有根本价值。

I would like to put my tests in the same project in C#/.NET/Visual Studio 2008, but I still haven't investigated this enought to achieve it.

我想将我的测试放在 C#/.NET/Visual Studio 2008 中的同一个项目中，但我仍然没有调查这足以实现它。

One big benefit of keeping Foo.cs in the same project as FooTest.cs is that developers are constantly reminded when a class is missing a sibling test! This encourages better test-driven coding practices...holes are more apparent.

将 Foo.cs 与 FooTest.cs 放在同一个项目中的一大好处是，当类缺少兄弟测试时，会不断提醒开发人员！这鼓励了更好的测试驱动编码实践......漏洞更加明显。

回答by sampablokuper

Separate projects, although I debate with myself whether they should share the same svn. At the moment, I'm giving them separate svn repositories, one called

单独的项目，尽管我与自己争论它们是否应该共享相同的 svn。目前，我给他们单独的 svn 存储库，一个叫做

"MyProject" - for the project itself

“MyProject” - 项目本身

and one called

一个叫

"MyProjectTests" - for the tests associated with MyProject.

“MyProjectTests” - 用于与 MyProject 相关的测试。

This is fairly clean and has the advantage that commits to the project and commits to the tests are quite separate. It also means you can hand over the project's svn if needed, without having to release your tests. It also means you can have branch/trunk/tag directories for your tests and for your project.

这是相当干净的，并且具有提交到项目和提交到测试完全分开的优点。这也意味着您可以在需要时移交项目的 svn，而无需发布您的测试。这也意味着您可以为您的测试和项目设置分支/主干/标签目录。

But I'm increasingly inclined to have something like the following, in a single svn repository, for each project.

但我越来越倾向于在单个 svn 存储库中为每个项目提供类似以下内容。

MyProject
|\Trunk
| |\Code
|  \Tests
|\Tags
| |##代码##.1
| | |\Code
| |  \Tests
|  ##代码##.2
|   |\Code
|    \Tests
\Branches
  \MyFork
   |\Code
    \Test

I'd be interested to know what other people think of this solution.

我很想知道其他人对这个解决方案的看法。

回答by sampablokuper

I am really inspired by the unit testing framework of the Flood NN libraryby Robert Lopez. It uses a different project for every single unit tested class, and has one solution holding all these projects, as well as a main project that compiles and runs all the tests.

我真的受到Robert Lopez的Flood NN 库的单元测试框架的启发。它为每个单元测试类使用不同的项目，并有一个解决方案来保存所有这些项目，以及一个编译和运行所有测试的主项目。

The neat thing is also the layout of the project. The source files are in a folder, but then the folder for the VS project is below. This allows you to make different subfolders for different compilers. All the VS projects are shipped with the code, so it is very easy for anyone to run any or all of the unit tests.

整洁的东西也是项目的布局。源文件在一个文件夹中，但 VS 项目的文件夹在下面。这允许您为不同的编译器创建不同的子文件夹。所有 VS 项目都附带代码，因此任何人都可以轻松运行任何或所有单元测试。

回答by jenspo

Put Unit tests in the same project as the code to achieve better encapsulation.

将单元测试与代码放在同一个项目中，以实现更好的封装。

You can easily test internal methods, which means you wont make methods public that should have been internal.

您可以轻松测试内部方法，这意味着您不会将本应为内部的方法公开。

Also it's really nice to have the unit tests close to the code you're writing. When you write a method you can easily find the corresponding unit tests because it's in the same project. When you build a assembly that includes unitTests, any errors in the unitTest will give you an compilereerror, so you must keep your unittest up-to-date, just to build. Having unittest in a seperate project, might cause some developers to forget building the unittest-project, and missing the broken tests for a while.

此外，让单元测试接近您正在编写的代码也非常好。当你编写一个方法时，你可以很容易地找到相应的单元测试，因为它在同一个项目中。当你构建一个包含 unitTests 的程序集时，unitTest 中的任何错误都会给你一个编译器错误，所以你必须保持你的单元测试是最新的，只是为了构建。在单独的项目中使用单元测试，可能会导致一些开发人员忘记构建单元测试项目，并暂时错过损坏的测试。

And you can remove the unit tests from the production code, by using compilation tags (IF #Debug).

您可以使用编译标记 (IF #Debug) 从生产代码中删除单元测试。

Automatic Integration Tests (made i NUnit) should be in a seperate project since they don't belong to any single project.

自动集成测试（由 NUnit 制作）应该在一个单独的项目中，因为它们不属于任何单个项目。

回答by Sebastian K

I would say keep them separate.

我会说把它们分开。

On top of the other reasons mentioned, having code and tests together skews test coverage numbers. When you report on unit test coverage - reported coverage is higher because the tests are covered when you run unit tests. When you report on integration test coverage, the reported coverage is lower because integration tests would not run unit tests.

除了提到的其他原因之外，将代码和测试放在一起会导致测试覆盖率数字出现偏差。当您报告单元测试覆盖率时 - 报告的覆盖率更高，因为在您运行单元测试时覆盖了测试。当您报告集成测试覆盖率时，报告的覆盖率较低，因为集成测试不会运行单元测试。