构建单元测试程序集的最佳方式？答案

【问题标题】：Best way to structure your Unit Test assemblies?构建单元测试程序集的最佳方式？
【发布时间】：2009-08-17 15:22:06
【问题描述】：

我想优化我的单元测试程序集。具体来说，我想确保多个开发人员可以同时工作而不会互相干扰。创建单元测试时的最佳实践是什么？每个真实类一个单元测试类，单元测试按关注而不是按类分解，所有类的一个大型单元测试类（我怀疑）等等？？

【问题讨论】：

标签： .net unit-testing tdd

【解决方案1】：

我喜欢 java 类约定的一个测试类。这样可以确保您始终知道在哪里可以找到测试，并且测试单元足够小，可以让很多人进行测试，而无需进行太多合并，因为它们都在一个文件中。

如果您有一个更大的测试套件并且您正在密切关注这一类，它还可以让您只运行一个类的测试。

【讨论】：

【解决方案2】：

有可能组织单元测试的树方法：

每个测试类的测试类中的TestMethod。最受欢迎的。
每个测试夹具的测试类中的TestMethod。允许最小化文本固定/拆卸代码。
每个被测系统的测试类中的TestMethod（子系统、模块、几个类）。

通常需要保留几个自动化测试程序集：

单元测试程序集 - 使用纯单元测试，即使用模拟、测试转储测试每个单元。
集成/消费者测试组件 - 旨在检查系统单元的集成，检查消费者关键功能是否正常工作。

【讨论】：

【解决方案3】：

我认为最好的方法是区分行为。每个测试类的一种行为。这意味着每个类都有几个测试类。可以在here找到一个相关的示例问题。

【讨论】：

【解决方案4】：

我倾向于采用的方法是单元测试的上下文规范样式，它将您的单元测试分解为行为分组；例如，如果我正在为一个名为作业状态页面的网站创建一个新的 ASP.NET 网页，我将有一个这样的目录结构：

unit-tests -> spec_for_job_status_page

其中 spec_for_job_status_page 是包含解决方案文件、csproj 文件和相关类的文件夹。

就单元测试类的结构而言，我喜欢使用遵循上下文规范样式的命名约定，例如：

namespace spec_for_job_status_page
{
    [TestFixture]
    public class when_the_job_status_page_is_loaded
    {
        [SetUp]
        public void context()
        {
            //write set-up code here for your test
        }

        [Test]
        public void should_show_the_job_number()
        {
            //write the assertion code here.  Should be a single line
        }
    }
}

【讨论】：