Gerätetest mit zwei Funktionen

Question

Ich habe den Gerätetest für einige Zeit vernachlässigt. Ich habe Unit-Tests geschrieben, aber sie waren ziemlich schlecht. Ich lese gerade durch "The Art of Unit Testing", um mich selbst auf den neuesten Stand zu bringen.

Wenn ich eine Schnittstelle haben, wie:

public interface INotificationService 
{ 
    void AddError(string _error); 
    void AddIssue(string _issue); 

    IEnumerable<string> FetchErrors(); 
    IEnumerable<string> FetchIssues(); 
} 

Eine konkrete Implementierung dieser Schnittstelle enthält:

private readonly ICollection<Message> messages; 

Hinzufügen eines Fehler oder Problem erstellt eine neue Nachricht mit einem Enum seiner Art bezeichnet und fügt es der Sammlung hinzu. Der Aufruf von FetchErrors()/FetchIssues() gibt Nachrichten dieses Typs aus der Auflistung zurück.

Würde der folgende Test gültig ?:

[Test] 
    public void FetchErrors_LoggingEnabledAddErrorFetchErrors_ReturnsError() 
    { 
     notificationService = new NotificationService(); 
     notificationService.AddError("A new error"); 

     Assert.AreEqual(new []{"A new error"}, notificationService.FetchErrors()); 
    } 

Meine Sorge ist, dass ich zum ersten Mal AddError() ich anrufen, dann das Ergebnis der Prüfung FetchErrors(). Also rufe ich zwei Funktionen an. Ist das falsch?

Sollte ich die Sammlung öffentlich machen und direkt bestätigen, dass sie eine Nachricht des entsprechenden Typs enthält, die die protokollierte Fehlermeldung enthält?

Was wäre die beste Vorgehensweise in diesem Szenario?

Answer 1

Ihr Ansatz sieht OK aus - das Testen der Implementierung über die öffentlichen Methoden ist der einzige verfügbare Zugriff im Design.

Um die Methoden unabhängig voneinander zu testen, müssten Sie eine White-Box-Backdoor testen, um auf die privaten Nachrichten zuzugreifen, um sicherzustellen, dass die entsprechenden Add* Methoden funktionieren. Dies ist keine gute Idee, da Ihre Tests jedes Mal, wenn sich die zugrunde liegende CUT-Implementierung ändert, (zur Laufzeit) unterbrochen werden.

Eine gemeinsame, bessere Alternative zur Reflexion ist eine nicht-Schnittstelle internal Methode auf dem Betonklasse im Test zu, die Ihnen irgendeine Art von ‚Wartungsklappe‘ Zugang zur ICollection<Message> messages; Implementierung Feld erlaubt und erlaubt dann InternalsVisibleTo Zugriff auf dem Komponententestmontage.

Ein Hinweis - Sie werden feststellen, dass Assert.AreEqual auf einem der String-Enumerable einen Referenzvergleich tun und somit fehlschlagen (weil Sie es mit einem neuen Array vergleichen).

Sie werden wahrscheinlich diese wie zu etwas ändern:

Assert.IsTrue(notificationService.FetchErrors().Contains("A new error")); 

bearbeiten

IMO brauchen Sie nicht so weit wie machen Sie das Feld public in .Net zu gehen. Da Sie die Schnittstellenabstraktion bereits an Ort und Stelle haben, die theoretisch die Zugriffsmöglichkeit auf die CUT einschränken sollte, ist es üblich, internal scope und InternalsVisibleTo zu verwenden, um den UT-Spezialzugriff zu erlauben. Jon Skeet et al haben mentioned this here

#region Unit Testing side-door 
internal ICollection<Message> Messages 
{ 
    get { return _messages }; 
    // No Setter 
} 
#endregion 

Answer 2

Ihr Ansatz ist vollkommen in Ordnung.Ein Komponententest sollte der Struktur Arrange-Act-Assert folgen - und Ihr Anruf bei notificationService.AddError(..) ist einfach ein Teil des Abschnitts Arrange des Tests.

Es ist nicht so, dass Sie nicht mehr als eine Methode in einem Test aufrufen können (in vielen Fällen müssen Sie), der Punkt ist, dass Sie nur für eine einzige Tatsache bestätigen/testen sollten. Das machst du, also sieht alles gut aus.

Answer 3

Wie andere darauf hingewiesen haben, ist es in Ordnung, beide Methoden zu verwenden. Sie testen das Verhalten der Klasse. Wenn ein Fehler veröffentlicht wird, können Sie ihn lesen.

Wenn die Implementierung komplizierter ist, dann müssen Sie wahrscheinlich das Design überdenken, da Ihre Methode (n) zu viel tun. Sehen Sie, was Sie beschreiben, warum eigentlich brauchen Sie den Getter, um eine Methode zu sein?

Im Allgemeinen mag ich nicht die Idee, interne Methode nur für Testzwecke freizulegen. Dies sendet eine falsche Nachricht an denjenigen, der diesen Code in der Zukunft beibehalten wird (auch Sie, nachdem Sie vergessen haben). Es sagt - ja, gehen Sie voran, greifen Sie auf diese Sammlung direkt von jeder Klasse in dieser Versammlung zu.

Answer 4

Wir können nicht sagen, ob Ihr Test gültig ist oder nicht, basierend auf dem von Ihnen geposteten Code. Wir wissen nicht, was AddError() tut, ist nicht möglich zu wissen, ob der Komponententest korrekt ist.

Wenn AddError nur einen Fehler in die Sammlung hinzufügen und alles andere tun, dann ist Ihr Test gut und Aufruf FetchErrors() ist gültig, weil es einen separaten Unit-Test haben muss, der es überprüft. In jedem Fall müssen Sie, wenn Ihre AddError-Methode etwas anderes tut, den Test ändern und alle Schritte dieser Methode überprüfen.