2010-05-06 11 views
6

Diese drei Tests sind identisch, außer dass sie eine andere statische Funktion verwenden, um eine StartInfo-Instanz zu erstellen. Ich habe dieses Muster alle durch meinen Testcode kommen, und würde gerne in der Lage sein, dies zu vereinfachen mit [TestCase], oder jede andere Möglichkeit, die Boilerplate-Code reduziert. Meines Wissens ist es mir nicht erlaubt, einen Delegierten als [Testfall] -Argument zu verwenden, und ich hoffe, dass die Leute hier kreative Ideen haben, wie man den Code unten knapper macht.Wie vereinfache ich diese NUNit-Tests?

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

Antwort

8

Erstens glaube ich nicht, dass das Original zu schlecht ist. Es ist nur unordentlich, wenn sich Ihre Behauptungen von Testfall zu Testfall unterscheiden.

Wie auch immer, Sie können einen Testfall verwenden, aber es kann nicht über ein Standard [TestCase] ​​-Attribut aufgrund der Verwendung von komplizierteren Typen erfolgen. Stattdessen müssen Sie einen öffentlichen IEnumerable <> als Datenanbieter verwenden und dann Ihre Testmethode mit einem [TestCaseSource]-Attribut versehen.

Probieren Sie etwas wie:

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

Dies ist eine kurze Version des Standardmusters von TestCaseData Instanzen wodurch man die Parameter enthält. Wenn Sie Instanzen von TestCaseData liefern, können Sie jedem Test weitere Informationen und Verhaltensweisen hinzufügen (wie erwartete Ausnahmen, Beschreibungen usw.), aber es ist etwas ausführlicher.

Ein Teil des Grundes, warum ich dieses Zeug wirklich mag, ist, dass Sie eine Methode für Ihre "Tat" und eine Methode für Ihre "Behauptung" machen können, dann mischen und sie unabhängig voneinander anpassen. Z.B. Mein Freund hat gestern etwas gemacht, wo er zwei Aktionen verwendet hat ("wenn Methode Blah aufgerufen wird, sollte diese Methode im ViewModel ausgelöst werden"). Sehr kurz und effektiv!

+1

brachte mir ein neues Konzept bei !!! plus +1 – Prashant

+0

+1 schön. Hier ist ein verbesserter [NUnit doc Link mit Beispielen] (http://nunit.org/index.php?p=testCaseSource&r=2.5.10). –

0

Es sieht gut aus. Möchten Sie vielleicht eine Fabrik hinzufügen? Oder Sie können diese Methoden zu einer Aktionsliste hinzufügen (in der Testkonfiguration) und den ersten Aktionsdelegaten, den zweiten Aktionsdelegaten und den dritten Aktionsdelegaten aufrufen.