2015-08-06 11 views
7

Ich habe die Verwendung von Xunit für Komponententests von NUnit migriert. Mit NUnit würde ich eine Methode mit mehreren Testfällen erstellen, die das gleiche Ergebnis haben. Der folgende NUnit-Komponententest testet beispielsweise die Validierung eines Klassenkonstruktors, insbesondere die Variable "name". Der Name darf nicht null, leer oder Leerzeichen sein. Der Test prüft, dass ein Argument richtig geworfen wird:Was ist der bevorzugte Weg, um mehrere Testfälle in Xunit zu behandeln?

[Test] 
    [TestCase(null)] 
    [TestCase("")] 
    [TestCase("  ")] 
    [ExpectedException(typeof(ArgumentNullException))] 
    public void Constructor_InvalidName_ExceptionThrown(string name) 
    { 
     // action 
     make_Foo(name); 
    } 

    private make_Foo(string name) 
    { 
     return new Foo(name); 
    } 

Dies ist, wie ich dies mit xUnit umgesetzt haben:

[Fact] 
    public void Constructor_InvalidName_ExceptionThrown() 
    { 
     Assert.Throws<ArgumentNullException>(() => new Foo(null)); 
     Assert.Throws<ArgumentNullException>(() => new Foo("")); 
     Assert.Throws<ArgumentNullException>(() => new Foo(" ")); 
    } 

Dies aus zwei Gründen schlecht scheint - ich mehrere haben Asserts in was soll sei ein "Einheits" -Test und mit den Testfällen, die innerhalb der Methode vergraben sind (was bei einigen der anderen Komponententests viel komplizierter werden könnte).

Was ist der bevorzugte Weg, um mehrere Testfälle in Xunit zu behandeln?

+1

XUnit hat einen Typ namens "Theory", den Sie verwenden können. –

+0

Für ein Beispiel von XUnit Theory-Attribut: schau [hier] (http://dontcodetired.com/blog/post/Creating-Inline-Data-Driven-Tests-in-xUnit.aspx) – prgmtc

Antwort

9

Sie können das Theory Attribut auf den gleichen Effekt:

[Theory()] 
[InlineData(null)] 
[InlineData("")] 
[InlineData("  ")] 
public void Constructor_InvalidName_ExceptionThrown(string name) 
{ 
    Assert.Throws<ArgumentNullException>(() => new Foo(name)); 
} 

Ich bin nicht sicher, ob xUnit Uhr jedoch Attribut entspricht ExpectedException hat. Wenn ja, I would not use it.

Es verwendet ein ExpectedException Attribut in xUnit zu sein, aber es hat deprecated in favour of Assert.Throws da gewesen.

Verwandte Themen