构造单元测试程序集的最佳方法?

组织单元测试有三种可能的方法:

1. 每个测试类的测试类中的测试方法。最受欢迎的一个。
2. 每个测试夹具的测试类中的测试方法。允许最小化文本设备/分解代码。
3. 每个被测系统的测试类中的测试方法(子系统、模块、几个类)。

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

• 单元测试组装-使用纯单元测试,即使用模拟、测试转储测试每个单元。
• 集成/用户测试组件-用于检查系统单元的集成,检查用户关键功能是否正常工作。

我喜欢Java中的类约定的一个测试类。这可以确保您始终知道在哪里找到一个测试,并且测试单元足够小,可以让许多人处理它们,而不必进行太多的合并,因为它们都在一个文件中。

如果您有一个更大的测试套件,并且您正在密切地处理这一个类,那么它还允许您仅为一个类运行测试。

我认为最好的办法是区分行为。每个测试类有一个行为。这意味着每个班都有几个最高级的班。可以找到一个有例子的相关问题 here .

我所采用的方法是将单元测试分解为行为分组的上下文规范样式的单元测试;例如,如果我正在为一个名为“作业状态页”的网站开发一个新的ASP.NET网页,我将拥有这样的目录结构:

unit-tests -> spec_for_job_status_page

其中spec_for_job_status_页是包含解决方案文件、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
        }
    }
}