Get best of the week

Bestätigen Sie Nachrichten in Tests

Hallo wieder. Im Vorgriff auf den Beginn des Kurses „C # Developer“ haben wir interessantes Material über Bestätigungsnachrichten in Tests übersetzt und teilen die Übersetzung gerne mit Ihnen.



In diesem Beitrag werden wir darüber sprechen, ob Sie Assert-Nachrichten in Ihren Tests verwenden sollten.

Ich habe eine interessante Frage von einem Leserkollegen erhalten , auf die ich näher eingehen möchte:

Ich habe eine Frage zu Assert-Nachrichten: Soll ich die Überladung mit dem Nachrichtenparameter verwenden und damit eine Zeichenfolge senden, die den Grund für das Versagen von Assert beschreibt (auch „Ansprüche“)? ?

Die Antwort auf diese Frage besteht aus zwei Aspekten:

  • Lesbarkeit des Tests - wie einfach es ist zu verstehen, was der Test tut.
  • Einfache Diagnose - wie einfach es ist zu verstehen, warum der Test fehlschlägt.

Lassen Sie uns jeden von ihnen einzeln diskutieren

Testlesbarkeit


Menschen verwenden häufig Assert-Nachrichten, um Teammitgliedern und sich selbst in Zukunft zu helfen, zu verstehen, was im Test passiert. Schauen wir uns das folgende Beispiel an:

[Test]
public void Hiring_a_new_team_member()
{
    var company = new Company();
    var person = new Person(UserType.Customer);

    company.HireNewMember(person);

    Assert.AreEqual(UserType.Employee, person.Type); //  
    Assert.AreEqual(1, company.NumberOfEmployees); //  
}

Anstelle einer bloßen Behauptung können Sie auch den Grund angeben, warum die Test-Behauptung etwas validiert:

[Test]
public void Hiring_a_new_team_member()
{
    var company = new Company();
    var person = new Person(UserType.Customer);

    company.HireNewMember(person);

    Assert.AreEqual(UserType.Employee, person.Type, "Person must become an employee after hiring");
    Assert.AreEqual(1, company.NumberOfEmployees, "Number of employees must increase");
}

Solche Aussagen helfen, aber sie haben ihren Preis. Diese Nachrichten erfordern Sie

  • Verbringen Sie Zeit damit, sie zu schreiben
  • Halte sie in Bewegung

Hier sind die Vor- und Nachteile dieselben wie in den Kommentaren zum Code. Und wie bei den Kommentaren rate ich Ihnen: Schreiben Sie Assert-Nachrichten nicht nur aus Gründen der Lesbarkeit. Wenn Sie der Meinung sind, dass der Test ohne Bestätigungsnachrichten nicht offensichtlich ist, versuchen Sie stattdessen, ihn umzugestalten. Auf lange Sicht ist es einfacher, den Test für sich selbst sprechen zu lassen, als ihn mit Bestätigungsnachrichten synchron zu halten (und dies ist nur eine Frage der Zeit, bis die Synchronisierung unterbrochen wird).

Geben Sie Bestätigungsnachrichten nur ein, wenn dies unbedingt erforderlich ist - wenn Sie die Lesbarkeit des Tests auf keine andere Weise verbessern können. Aber selbst dann neigen Sie dazu, sie nicht zu schreiben.

Der einfachste Weg, um die Lesbarkeit von Tests schnell zu verbessern, besteht darin, zu einem lesbaren Anweisungsdatensatz zu wechseln. Beispielsweise verfügt NUnit über ein spezielles, auf Einschränkungen basierendes Anweisungsmodell, mit dem Sie Ihre Anweisungen folgendermaßen schreiben können:

[Test]
public void Hiring_a_new_team_member()
{
    var company = new Company();
    var person = new Person(UserType.Customer);

    company.HireNewMember(person);

    Assert.That(person.Type, Is.EqualTo(UserType.Employee));
    Assert.That(company.NumberOfEmployees, Is.EqualTo(1));
}

Oder Sie können meine bevorzugten fließenden Behauptungen verwenden :

[Test]
public void Hiring_a_new_team_member()
{
    var company = new Company();
    var person = new Person(UserType.Customer);

    company.HireNewMember(person);

    person.Type.Should().Be(UserType.Employee);
    company.NumberOfEmployees.Should().Be(1);
}

Diese Anweisungen werden im Klartext gelesen - genau so, wie Sie möchten, dass Ihr gesamter Code gelesen wird. Wir Menschen ziehen es vor, Informationen in Form von Geschichten wahrzunehmen. Alle Geschichten halten an diesem Modell fest:

[] [] [].

Zum Beispiel,

  .

Hier - das Subjekt, - die Handlung und - das Objekt. Gleiches gilt für Code.

Diese Version

company.NumberOfEmployees.Should().Be(1);

liest sich besser als

Assert.AreEqual(1, company.NumberOfEmployees);

gerade weil hier Geschichte verfolgt wird.
, . , .


Eine andere Sichtweise von Bestätigungsnachrichten betrifft die einfache Diagnose. Mit anderen Worten, die Einfachheit, die Ursache eines Testfehlers zu verstehen, ohne den Code für diesen Test zu untersuchen. Dies ist nützlich, wenn Sie die Ergebnisse der CI-Assembly lesen.

Befolgen Sie aus diagnostischer Sicht diese Anleitung: Wenn Sie den Test lokal problemlos neu starten können, benötigt dieser Test keine Bestätigungsmeldung. Dies gilt für alle Komponententests (da sie nicht mit Abhängigkeiten außerhalb des Prozesses arbeiten), in geringerem Maße jedoch für Integrations- und End-to-End-Tests.


Testpyramide

Wenn Sie in der Testpyramide höher klettern, benötigen Sie möglicherweise detailliertere Informationen, da Integrationstests (und insbesondere End-to-End-Tests) langsamer sind und Sie sie möglicherweise nicht nach Belieben erneut ausführen können.

Aber auch bei Integrations- und End-to-End-Tests gibt es Möglichkeiten, die Diagnose zu vereinfachen, ohne auf die Bestätigung von Nachrichten zurückgreifen zu müssen:

  • Machen Sie den Test zu einem Verhaltensmodul - wenn ein Test eine Sache überprüft, ist es oft einfach festzustellen, was schief gelaufen ist. (Dies gilt nicht immer für End-to-End-Tests, da diese Tests möglicherweise überprüfen sollen, wie mehrere Verhaltenseinheiten eng zusammenarbeiten.)
  • Benennen Sie Ihre Komponententests entsprechend - Der ideale Testname beschreibt das Verhalten der Anwendung in geschäftlicher Hinsicht, sodass auch Nicht-Programmierer es verstehen können.

Und vergessen Sie nicht, dass Sie auch ohne Benutzeranweisungen die Nachrichten haben, die die Unit-Test-Umgebung für Sie generiert.

Zum Beispiel ein Fehler in der folgenden Anweisung:

person.Type.Should().Be(UserType.Employee);

gibt die folgende Fehlermeldung aus:

Xunit.Sdk.EqualException: Assert.Equal() Failure
Expected: Employee
Actual:   Customer

Die Kombination solcher Nachrichten, die von der Umgebung generiert werden, und von Menschen lesbaren Testnamen macht 90% der vom Benutzer behaupteten Nachrichten selbst im Hinblick auf eine einfache Diagnose unbrauchbar. Die einzige Ausnahme sind langwierige End-to-End-Tests. Sie enthalten häufig mehrstufige Überprüfungen. Daher ist es sinnvoll, zusätzliche Bestätigungsnachrichten zu verwenden, um zu verstehen, welcher der Schritte fehlgeschlagen ist. Es sollte jedoch nicht viele solcher End-to-End-Tests geben.

Um die vom Framework generierten Fehlermeldungen nutzen zu können, müssen Sie natürlich häufige boolesche Vergleiche vermeiden, wie z.

(person.Type == UserType.Employee).Should().BeTrue();

Weil sie zu folgender Fehlermeldung führen:

Xunit.Sdk.TrueException: Assert.True() Failure
Expected: True
Actual:   False

Was bei der Diagnose überhaupt nicht hilft.

Zusammenfassung


Fühlen Sie sich oft faul, wenn Sie Aussagen schreiben? Nun können Sie dies begründen und Ihre Kollegen zu diesem Artikel schicken.


"Ich bin froh, dass dies einen Namen hat"

Scherze beiseite, hier ist eine Zusammenfassung:

  • Die Verwendung von Assert-Nachrichten hat zwei Aspekte:
    • Lesbarkeit des Tests (wie einfach es ist zu verstehen, was der Test tut).
    • Einfache Diagnose (wie einfach es ist zu verstehen, warum der Test während der CI-Erstellung fehlschlägt).
  • In Bezug auf die Testlesbarkeit sind Assert-Nachrichten Codekommentare. Anstatt sich auf sie zu verlassen, überarbeiten Sie Ihren Test, um Lesbarkeit zu erreichen.
  • In Bezug auf die einfache Diagnose ist die beste Alternative zur Bestätigung von Nachrichten:
    • Testen eines einzelnen Verhaltensmoduls durch einen Test
    • Benennungstests in geschäftlicher Hinsicht
  • Die einzige Ausnahme sind langwierige End-to-End-Tests.

Das ist alles. Weitere Informationen zu unserem Kurs erhalten Sie im kostenlosen Webinar , das heute stattfindet.

More articles:


All Articles