AssertThat, AssertEquals, AssertTrue

Gestern Abend fand die Veranstaltung „Tag der offenen Tür“ von AgileChina 2011 statt, und ich nahm ehrenamtlich an der Programmiersitzung teil. Der Hauptzweck der Coding-Sitzung besteht darin, den teilnehmenden Entwicklern den Prozess der Paarprogrammierung, der testgetriebenen Entwicklung und des Refactorings näherzubringen. Wir haben vier verschiedene Arten von Programmierfragen vorbereitet. Acht oder neun Kollegen aus dem Unternehmen und teilnehmende Kollegen werden diesen Prozess gemeinsam erleben:

Stundenzettel

Supermarktkasse

Statistik von Quellcodezeilen

Blackjack-Spiel

Insgesamt war die Veranstaltung recht erfolgreich, bis auf zwei kleine Episoden:

1. Die Firma wollte mir eine neue Tastatur und Maus kaufen , aber sie fühlen sich beim Tippen zu taktil an und die Tasten der Tastatur sind flach. Ein Teilnehmer ist möglicherweise nicht sehr vertraut mit der Tastatur und tippt mehrmals fälschlicherweise die Eingabetaste in einen Schrägstrich ein.

2. Die Tastenkombinationen für den Sperrbildschirm des Systems stehen in Konflikt mit den Tastenkombinationen für den Formatierungscode, was dazu führte, dass ich den Bildschirm sperrte, indem ich zweimal die falsche Taste eingab. Außerdem gehörte mir das Gerät nicht andere Kollegen zu finden, die mir bei der Eingabe des Passworts helfen, verdammt.

In der letzten Runde von Pair fragte ein Student: Warum nicht „assertEquals“ verwenden? Ich sehe, dass Sie alle „asserThat“ verwenden, und es scheint, dass die Verwendung von „asserEquals“, „asserTrue“ usw. nicht dringend empfohlen wird.

Da die Veranstaltung fast vorbei war und wir ein Gruppenfoto machen wollten, antworteten wir einfach. Hier finden Sie eine ausführliche Antwort auf diese Frage.

Was wollen wir von Behauptungen bekommen?

Was wollen wir von Behauptungen in Tests bekommen? Wir wollen nicht nur einen roten Balken anzeigen, nachdem ein Test fehlgeschlagen ist. Außerdem möchten wir einige Informationen aus dem Test erhalten:

1. Gibt es eine Codezeile? Alle Behauptungen können diese Funktion bereitstellen

2. Warum der Test fehlgeschlagen ist, ist schwer zu definieren. Die meisten Behauptungen können eine ähnliche Funktionalität bieten:

Gewünschtes Ergebnis vs. tatsächliches Ergebnis

Aber unterschiedliche Behauptungen liefern unterschiedliche Informationen. Es gibt auch Probleme, bei denen es schwierig ist, Vergleiche anhand einfacher Aussagen wie Gleichheit anzustellen. Darüber hinaus spielen Behauptungen auch eine sehr wichtige Rolle: die Dokumentation. Das heißt, wenn Sie den Testcode lesen, sehen Sie die Behauptungen so, als ob Sie alle Erwartungen sehen würden. Und ganz klare Erwartungen.

Eigentliches Beispiel

Sehen Sie sich den zweiten Parameter von „asserThat“ an. Er akzeptiert einen Matcher8742468051c85b06f0a0af9e3e506b5c. Es gibt sehr umfangreiche Matcher-Implementierungen in org.hamcrest. Beispielsweise gibt unsere API jetzt eine Liste von Benutzerobjekten zurück. Wir möchten sicherstellen, dass diese Liste den von uns erwarteten Benutzer enthält. Es gibt einen Matcher wie hasItem in hamcrest:

   1: assertThat(userDAO.findAll(), hasItem(expected));

Was tun, wenn andere Behauptungen werden verwendet?

   1: assertTrue(userDAO.findAll().contains(expected));

Okay, hier ist das Problem: Wenn beide oben genannten Behauptungen fehlschlagen, lautet die Fehlermeldung der ersten Behauptung:

Das erwartete Ergebnis enthält erwartet….

Aber eigentlich ... werden alle von findAll zurückgegebenen Benutzer ausgedruckt

Und was ist mit der zweiten Behauptung? Es ist so:

Erwartet, dass es wahr ist, tatsächlich falsch

Welches ist zuverlässiger? Offensichtlich sind die Fehlerinformationen der ersten Behauptung für uns hilfreicher, um das Problem zu finden.

Zur Dokumentation schauen wir uns diese Anforderung an: Stellen Sie sicher, dass die zurückgegebene Benutzerliste keinen bestimmten Benutzer enthält:

   1: assertThat(userDAO.findAll(), not(hasItem(expected));

Ist das nicht sehr klar? Sie werden das nicht lesen Behauptung Sie werden das Gefühl haben, Sie würden Code lesen, genau wie beim Lesen von Spec. Wenn andere Behauptungen verwendet werden:

   1: assertFalse(userDAO.findAll().contains(expected));

sind nicht so gut dokumentiert wie die vorherige.

Natürlich können Sie für einige APIs, die „true“ oder „false“ oder einen einzelnen Wert zurückgeben, ohne große Probleme auch andere Behauptungen verwenden. Zum Beispiel:

   1: assertEquals(userDAO.findBy(id), expected);

Ah, was? Du hast gesagt, ich hätte es falsch benutzt, warum? Nachdem ich die Parameterbeschreibung überprüft hatte, stellte ich fest, dass der erwartete Wert im ersten Parameter und der tatsächliche Wert im zweiten Parameter platziert werden sollte. Es ist so hilflos, dass ich immer Fehler mache.

   1: assertThat(userDAO.findBy(id), is(expected));

Werden Sie immer noch Fehler machen?

Das Obige ist der Inhalt von „asserThat“, „assertEquals“, „assertTrue“ Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!