Als ich zum ersten Mal auf das Schreiben von Tests für einen Mikroservice stieß, dessen API gemäß dem JSON-RPC-Protokoll implementiert wurde, stellte ich fest, dass das Erstellen von Qualitätsprüfungen für JSON-Elemente sehr viel anspruchsvoller ist als gedacht.
Das Folgende ist ein einfaches Beispiel.
Es wurde eine Antwort vom Dienst erhalten:
{ "result": 12, "id": 46929734, "jsonrpc": "2.0" }
Was Sie überprüfen müssen:
- Die Antwort enthält ein jsonrpc- Element und der Wert ist 2.0
- Die Antwort enthält ein id- Element und sein Wert entspricht einem ähnlichen Element, das in der Anforderung übergeben wurde. Nehmen wir an, es ist momentan 46929734
Die Antwort enthält das Element
"result" und der Wert ist
12So überprüfen Sie dies mit Java + TestNG + Gson:
Assert.assertTrue(response.has("result")); Assert.assertTrue(response.has("jsonrpc")); Assert.assertTrue(response.has("id")); Assert.assertTrue(response.get("result").isJsonPrimitive()); Assert.assertTrue(response.get("jsonrpc").isJsonPrimitive()); Assert.assertTrue(response.get("id").isJsonPrimitive()); Assert.assertEquals(response.get("result").getAsInt(), 12); Assert.assertEquals(response.get("jsonrpc").getAsString(), "2.0"); Assert.assertEquals(response.get("id").getAsInt(), 46929734);
In diesem Moment kann sich die Frage „Warum gibt es so viele Behauptungen?“ Im Kopf bilden. Ja, in der Tat, wenn Sie testen, interessieren Sie sich nur für die Gruppe der letzten drei Behauptungen, sie überprüfen die json-Werte der Elemente in der Antwort und wenn sie bestanden werden, erfüllt die Antwort die Erwartungen. Aber was ist, wenn der Test fehlschlägt? Betrachten Sie mehrere mögliche Gründe für den Sturz eines solchen Tests:
- Antwort ->
{ "result": 12, "id": 46929734, "jsonrpc": "1.0" }
Fehler von TestNG -> java.lang.AssertionError: erwartet [2.0] aber gefunden [1.0]
Sie haben auf "2.0" gewartet, "1.0" bekommen - hier ist alles klar.
- Antwort ->
{ "result": 12, "id": 46929734, "jsonrpc": {} }
Fehler von TestNG -> java.lang.UnsupportedOperationException: JsonObject
Sie versuchten, ein Element als String zu analysieren, was in der Antwort als Objekt völlig unerwartet auftauchte.
- Antwort ->
{ "result": 12, "id": 46929734 }
Fehler von TestNG -> java.lang.NullPointerException
Wir haben versucht, ein Element, das nicht in der Antwort enthalten ist, als Zeichenfolge zu analysieren.
Mit dem ersten Beispiel ist alles in Ordnung. Der Fehler ist verständlich, die tatsächlichen und erwarteten Werte sind sofort sichtbar. Aber das zweite und dritte Beispiel können sich nicht rühmen. Solch ein Abfall benötigt die Zeit des Testers, um die Ursache zu analysieren. Das Abrechnen eines solchen oberflächlichen Fehlers ist schwierig. Es wird einige Zeit dauern, um zu verstehen, welches Element der Test zu analysieren versuchte, welche Methode er zu analysieren versuchte und wie dieses Element tatsächlich in der Antwort aussah. Möglicherweise müssen Sie den Test sogar lokal neu starten, weil er möglicherweise schneller ist, als alle erforderlichen Informationen aus den Protokollen der Testassembly zu erfassen.
Eine solche Anzahl von Schecks, die Notwendigkeit, sie zu schreiben und auf dem neuesten Stand zu halten, hat mich sehr verärgert. Deshalb habe ich eine separate Bibliothek erstellt, in der ich meiner Meinung nach alle erforderlichen Schecks für JSON-Elemente gesammelt habe. Die gleiche Abdeckung und Detailgenauigkeit, die für die Verwendung der Bibliothek erforderlich war, wird in drei statt in neun Zeilen erzielt.
Gassert.verifyInteger(response, "result", 12); Gassert.verifyString(response, "jsonrpc", "2.0"); Gassert.verifyInteger(response, "id", 46929734);
Die Bibliothek implementiert Methoden zur Überprüfung von:
- Elemente aller primitiven Typen, verschachtelt und nicht, mit und ohne Wertprüfung
- JsonObject, verschachtelt und nicht, mit und ohne Wertprüfung
- JsonArray, verschachtelt und nicht, mit und ohne Wertprüfung
- JsonNull-Elemente verschachtelt und nein
- Elementtypen innerhalb eines Arrays
- den Inhalt des erwarteten Elementarrays
- Array-Dimensionen
- Objektabmessungen
Auf allen Überprüfungsebenen werden detailliertere Fehler im Vergleich zu denen implementiert, die TestNG standardmäßig bereitstellt.
Betrachten Sie noch einmal die möglichen Ursachen des Testfalls:
- Antwort ->
{ "result": 12, "id": 46929734, "jsonrpc": "1.0" }
Fehler von Gassert -> java.lang.AssertionError: Überprüfung des Elements [jsonrpc] fehlgeschlagen. erwartet [2.0] aber gefunden [1.0]
- Antwort ->
{ "result": 12, "id": 46929734, "jsonrpc": {} }
Fehler von Gassert -> java.lang.AssertionError: Element [jsonrpc] ist kein JsonPrimitive. habe nicht erwartet, [wahr] zu finden, aber [falsch] gefunden
- Antwort ->
{ "result": 12, "id": 46929734 }
Fehler von Gassert -> java.lang.AssertionError: Json enthält kein Element: [jsonrpc]. habe nicht erwartet, [wahr] zu finden, aber [falsch] gefunden
Außerdem sind die meisten Methoden für Überprüfungen mit einem zusätzlichen Zeichenfolgenparameter überladen, der im Fall eines Assertionsabfalls zum Text des angezeigten Fehlers hinzugefügt wird. Diese Funktion kann zum Beispiel verwendet werden, um den gesamten Inhalt einer Antwort oder eine Anfrage + Antwort im Fehlerfall anzuzeigen.
Die Bibliothek befindet sich im öffentlichen Github-Repository und wird auch dem Maven-Repository hinzugefügt.
MavenGithubAPIDocs