Question

这三个测试是相同的，只是它们使用不同的静态函数来创建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
    }

Answer 1

首先，我不认为原件太糟糕了。如果你的断言与测试用例和测试用例不同，那就太乱了。

无论如何，可以使用测试用例，但由于使用了更复杂的类型，无法通过标准[TestCase]属性来完成。相反，您需要使用公共IEnumerable＆lt;＆gt;作为数据提供者，然后使用[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上的这个方法”）。非常简洁有效！

Answer 2

看起来不错。您是否想要添加工厂？或者您可以将这些方法添加到动作列表（在测试设置中）并调用第一个动作委托，第二个动作委托和第三个动作委托。

如何简化这些NUNit测试？

2 个答案: