基于场景的单元测试：组织

Question

我和朋友最近发现了scenario-based unit testing的想法，我们认为这是对每类测试用例方法的一个很好的替代方案。它特别有吸引力，因为它有助于整合我们的大部分设置代码并减少创建测试所需的时间。但是为每个场景创建一个新的测试夹具给我们带来了一个新问题：我们应该如何组织这些场景测试夹具？

如果我们为每个场景创建一个新的测试夹具，我们将创建很多夹具。我们把它们放在哪里？在一个文件的单一猛犸象？或者我们应该为每个场景创建一个新文件，并将该文件放在包含所有其他测试装置的文件夹中？

我之所以提出这个问题的原因是因为当我们以后必须维护我们的代码时，我们有很大的可能会给自己造成很大的麻烦，但是在损坏完成之后我们就无法告诉它。 / p>

Answer 1

基于场景的测试非常棒，如何组织测试肯定有很多选择。

嵌套类

这种测试方式的一个关键是我们实际上使用嵌套类来表示我们的场景。我们创建一个表示所有测试的容器的根类，然后每个场景都是派生类。

[TestFixture]
public class MyClassSpecs
{
    // common helper methods here

    // additional specs/scenarios here...
    [TestFixture]
    public class WhenTheViewIsLoaded : MyClassSpecs
    {
        [Test]
        public void EnsureThatTheButtonIsEnabled()
        {
           /* etc */
        }
    }
}

在NUnit中，子类被展平，根和嵌套类名显示为Fixture名称的一部分：

MyClassSpecs+WhenTheViewIsLoaded
   > EnsureThatTheButtonIsEnabled

在我的项目中，我通常会为每个主题创建一个类文件，并将所有方案保留为嵌套类。我使用Visual Studio的大纲来折叠嵌套类。通过这种方式，我可以很快地看到所有场景。

每个场景的文件

戴夫的帖子中有一点很有意思，就是他正在使用部分课程。他这样做是因为它使得在Resharper中导航变得更容易，但这也意味着灯具可以分解成不同的文件。

MyClassSpecs.Scenario1.cs
MyClassSpecs.Scenario2.cs

将灯具拆分成多个文件可能是一个品味问题，但这是一个非常有趣的想法。我可以看到它崩溃的一个领域是用于文件的命名约定，特别是如果场景名称很长或需要更改。

就个人而言，如果有必要，我只会拆分成多个文件。

每个测试策略的文件

虽然我个人不赞成将我的灯具分成多个文件，但我可以看到一个很有意义的领域是你有不同的测试策略。例如，考虑两种测试策略，其中一组单元测试使用Mock对象作为依赖项，另一组使用具体依赖项。

MySpecs.UsingMocks.cs
MySpecs.Integration.cs

关于使用子类进行测试夹具的建议 - 这些测试的可读性是主要考虑因素 - 不要因为从测试中抽象出细节而被遗忘，并且不要创建使用多个测试夹具的测试夹具继承水平，你会没事的。

Answer 2

你所描述的对我来说听起来很像BDD - 行为驱动开发。从语义上讲，你谈的是规范，而不是测试。而且你的规范是作为一系列场景编写的，通常以像Given-When-Then（简称GWT）这样的格式编写。这意味着给定系统处于某种状态当执行某个操作时然后发生_可观察到的更改。 有许多实现来处理这个问题。我目前最喜欢的是mspec（机器规格），一个适用于NUnit或XUnit.Net的框架。其他包括Specflow和RSpec（基于ruby的实现）。

MSpec的一个好处是，每个规范（测试）都由委托构成，这些委托定义了初始状态，动作和预期结果（断言）。这意味着您可以在辅助类中定义每个这一个，并根据需要调用它们，混合和匹配，这是您永远不能使用继承层次结构。

希望这有帮助， 阿萨弗。