Question

These three tests are identical, except that they use a different static function to create a StartInfo instance. I have this pattern coming up all trough my testcode, and would love
to be be able to simplify this using [TestCase], or any other way that reduces boilerplate code. To the best of my knowledge I’m not allowed to use a delegate as a [TestCase] argument, and I’m hoping people here have creative ideas on how to make the code below more terse.

    [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

Firstly, I don’t think the original is too bad. It’s only messy if your assertions are different from test case to test case.

Anyway, you can use a test case, but it can’t be done via a standard [TestCase] attribute due to using more complicated types. Instead, you need to use a public IEnumerable<> as the data provider and then tag your test method with a [TestCaseSource] attribute.

Try something like:

    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
    }
}

This is a more concise version of the standard pattern of yielding TestCaseData instances containing the parameters. If you yield instances of TestCaseData you can add more information and behaviours to each test (like expected exceptions, descriptions and so forth), but it is slightly more verbose.

Part of the reason I really like this stuff is that you can make one method for your ‘act’ and one method for your ‘assert’, then mix and match them independently. E.g. my friend was doing something yesterday where he used two Actions to say (“when method Blah is called, this method on the ViewModel should be triggered”). Very terse and effective!