Unterstützt MSpec "Row-Tests" oder datengesteuerte Tests, wie NUnit TestCase?

Question

Wir verwenden Machine.Specification als unser Testframework für mein aktuelles Projekt. Dies funktioniert gut für die meisten von dem, was wir testen. Wir haben jedoch eine Reihe von Ansichtsmodellen, in denen wir Eigenschaften "formatiert" haben, die einige Rohdaten aufnehmen, eine gewisse Logik anwenden und eine formatierte Version dieser Daten zurückgeben.

Da bei der Formatierung eine Logik involviert ist (Nullprüfungen, Sonderfälle für Null usw.) möchte ich eine Anzahl möglicher Datenwerte einschließlich Randbedingungen testen. Für mich ist dies nicht der richtige Anwendungsfall für MSpec, und wir sollten auf etwas wie NUnit zurückgreifen, wo ich einen datengesteuerten Test schreiben kann, der etwas wie das Attribut [TestCase] ​​verwendet.

Gibt es eine saubere, einfache Möglichkeit, diese Art von Test in MSpec zu schreiben, oder habe ich recht mit dem Gefühl, dass wir ein anderes Tool für diese Art von Test verwenden sollten?

Ansicht Modell

public class DwellingInformation 
{   
    public DateTime? PurchaseDate { get; set; } 
    public string PurchaseDateFormatted 
    { 
     if(PurchaseDate == null) 
      return "N/A"; 

     return PurchaseDate.Value.ToShortDateString(); 
    } 

    public int? ReplacementCost { get; set; } 
    public string ReplacementCostFormatted 
    { 
     if(ReplacementCost == null) 
      return "N/A"; 

     if(ReplacementCost == 0) 
      return "Not Set"; 

     return ReplacementCost.ToString("C0"); 
    } 

    // ... and so on... 
} 

MSpec Tests

public class When_ReplacementCost_is_null 
{ 
    private static DwellingInformation information; 

    Establish context =() => 
    { 
     information = new DwellingInformation { ReplacementCost = null }; 
    }; 

    It ReplacementCostFormatted_should_be_Not_Available =() => information.ReplacementCostFormatted.ShouldEqual("N/A"); 
} 

public class When_ReplacementCost_is_zero 
{ 
    private static DwellingInformation information; 

    Establish context =() => 
    { 
     information = new DwellingInformation { ReplacementCost = "0" }; 
    }; 

    It ReplacementCostFormatted_should_be_Not_Set =() => information.ReplacementCostFormatted.ShouldEqual("Not Set"); 
} 

public class When_ReplacementCost_is_a_non_zero_value 
{ 
    private static DwellingInformation information; 

    Establish context =() => 
    { 
     information = new DwellingInformation { ReplacementCost = 200000 }; 
    }; 

    It ReplacementCostFormatted_should_be_formatted_as_currency =() => information.ReplacementCostFormatted.ShouldEqual("$200,000"); 
} 

NUnit w/Testcase

[TestCase(null, "N/A")] 
[TestCase(0, "Not Set")] 
[TestCase(200000, "$200,000")] 
public void ReplacementCostFormatted_Correctly_Formats_Values(int? inputVal, string expectedVal) 
{ 
    var information = new DwellingInformation { ReplacementCost = inputVal }; 
    information.ReplacementCostFormatted.ShouldEqual(expectedVal); 
} 

Gibt es eine bessere w ay, um die MSpec-Tests zu schreiben, die ich vermisse, weil ich mit MSpec noch nicht genug vertraut bin, oder ist MSpec in diesem Fall wirklich nur das falsche Werkzeug für den Job?

HINWEIS: Ein anderer Entwickler im Team ist der Meinung, dass wir alle unsere Tests in MSpec schreiben sollten, da er nicht mehrere Test-Frameworks in das Projekt einbinden möchte. Während ich seinen Standpunkt verstehe, möchte ich sicherstellen, dass wir das richtige Werkzeug für den richtigen Job verwenden. Wenn MSpec nicht das richtige Werkzeug ist, suche ich nach Punkten, die ich verwenden kann, um für die Einführung eines anderen Frameworks zu argumentieren.

Answer 1

Kurze Antwort, verwenden Sie NUnit oder Xunit. Kombinatorisches Testen ist nicht der Sweet Spot von MSpec und wird es wahrscheinlich nie sein. Ich habe mich in meinen Projekten nie um mehrere Test-Frameworks gekümmert, besonders wenn ein zweites Tool für bestimmte Szenarien besser funktioniert. Mspec funktioniert am besten für Verhaltensspezifikationen. Das Testen von Eingabevarianten ist nicht möglich.