6

这三个测试是相同的，只是它们使用不同的静态函数来创建 StartInfo 实例。我的测试代码中都出现了这种模式，并且希望能够使用 [TestCase] 或任何其他减少样板代码的方式来简化它。据我所知，我不允许使用委托作为 [TestCase] 参数，我希望这里的人们对如何使下面的代码更简洁有创意。

    [Test]
    public void ResponseHeadersWorkinPlatform1()
    {
        DoResponseHeadersWorkTest(Platform1StartInfo.CreateOneRunning);
    }
    [Test]
    public void ResponseHeadersWorkinPlatform2()
    {
        DoResponseHeadersWorkTest(Platform2StartInfo.CreateOneRunning);
    }
    [Test]
    public void ResponseHeadersWorkinPlatform3()
    {
        DoResponseHeadersWorkTest(Platform3StartInfo.CreateOneRunning);
    }

    void DoResponseHeadersWorkTest(Func<ScriptResource,StartInfo> startInfoCreator)
    {
        ScriptResource sr = ScriptResource.Default;
        var process = startInfoCreator(sr).Start();
        //assert some things here
    }
4

2 回答 2

8

首先，我不认为原版太糟糕了。只有当您的断言与测试用例不同时，它才会变得混乱。

无论如何，您可以使用测试用例，但由于使用了更复杂的类型，因此无法通过标准的 [TestCase] 属性来完成。相反，您需要使用公共 IEnumerable<> 作为数据提供者，然后使用[TestCaseSource]属性标记您的测试方法。

尝试类似：

    public IEnumerable<Func<ScriptResource, StartInfo>> TestCases
    {
        get
        {
            yield return Platform1StartInfo.CreateOneRunning;
            yield return Platform2StartInfo.CreateOneRunning;
            yield return Platform3StartInfo.CreateOneRunning;
        }
    }

    [TestCaseSource("TestCases")]
    public void MyDataDrivenTest(Func<ScriptResource, StartInfo> startInfoCreator)
    {
        ScriptResource sr = ScriptResource.Default;
        var process = startInfoCreator(sr);

        // do asserts
    }
}

这是产生包含参数的 TestCaseData 实例的标准模式的更简洁版本。如果您生成 TestCaseData 的实例，您可以为每个测试添加更多信息和行为（如预期的异常、描述等），但它会稍微冗长一些。

我真正喜欢这些东西的部分原因是您可以为您的“行为”制作一种方法，为您的“断言”制作一种方法，然后独立混合和匹配它们。例如，我的朋友昨天在做某事，他使用了两个动​​作来表示（“当调用 Blah 方法时，应该触发 ViewModel 上的这个方法”）。非常简洁有效！

于 2010-05-06T22:00:50.560 回答
0

这看起来不错的样子。您是否正在寻找添加工厂？或者您可以将这些方法添加到操作列表（在测试设置中）并调用第一个操作委托、第二个操作委托和第三个操作委托。

于 2010-05-06T22:00:01.810 回答