2010-03-24 4 views
6

Mein aktuelles Projekt verwendet JSON als Datenaustauschformat. Sowohl das Front-End- als auch das Back-End-Team einigen sich auf eine JSON-Struktur, bevor Sie mit der Integration eines Service beginnen. Manchmal aufgrund von nicht gemeldeten Änderungen der JSON-Struktur durch das Back-End-Team; Es bricht den Front-End-Code.Wie JSON-Antwort Server geltend machen/Unit-Test?

Gibt es eine externe Bibliothek, die wir verwenden könnten, um eine Schein JSON (Fixture) mit Server JSON Antwort zu vergleichen. Im Grunde sollte es das gesamte JSON-Objekt aktivieren und sollte einen Fehler auslösen, wenn ein Verstoß im Server-JSON-Format vorliegt.

Zusätzliche Informationen: App baut auf JQuery REST JSON-Dienste.

Antwort

6

Ich würde ein Schema für Ihre JSON-Objekte empfehlen.

Ich benutze Kwalify aber Sie können Rx, wenn Sie auch besser so Syntax.

+0

Deklarieren von Schema für JSON ist jedoch interessant.Hier ist meine Idee über Fixtures Ansatz; Es könnte sowohl zum Testen der Integrität von Back-End-Diensten als auch zur Offline- oder Vorintegrations-UI-Entwicklung verwendet werden. – shazmoh

+2

Mischen Sie diese Dinge nicht. Verwenden Sie ein Schema, um sicherzustellen, dass Sie beide den Datenvertrag verstehen. Verwenden Sie Fixtures im Backend, um Komponententests durchzuführen. Wenn Sie sie mischen, werden Sie zu viele Dinge aktualisieren und Ihr Leben komplizieren. –

3

Sieht aus wie Sie versuchen, ein Problem vom anderen Ende zu lösen. Warum sollten Sie sich als Frontend-Entwickler mit dem Testen der Backend-Entwickler beschäftigen?

Ein JSON, der auf einem Server generiert wird, ist besser auf einem Server zu testen, der den Standardansatz verwendet, d. H. Funktionale Tests in xUnit. Sie können sich auch Abnahmetest-Frameworks wie FITnesse ansehen, wenn Sie Tests und Dokumentations-Wiki in einem haben möchten.

Wenn Sie auch nach der Einführung von Tests auf dem Server ungültige JSON erhalten, ist dies ein Problem in der menschlichen Kommunikation, nicht in Tests.

+1

Ich stimme nicht zu. Obwohl das Back-End bei der Prüfung des eigenen Codes eine bessere Arbeit leisten sollte, gibt es so viele Möglichkeiten, dass Sie sicherstellen können, dass Sie die Art von Daten erhalten, die Sie erwarten. Durch die Möglichkeit, den eingehenden JSON schnell zu überprüfen, können Sie die Debugging-Zeit erheblich reduzieren, indem Sie das Problem als Frontend oder Backend identifizieren – Hortitude

5

Ich habe QUnit: http://docs.jquery.com/QUnit vor kurzem für eine Menge von meinem JS-Code verwendet.

asyncTest http://docs.jquery.com/QUnit/asyncTest könnte ziemlich effektiv verwendet werden, um JSON-Struktur zu testen.

Beispiel:


asyncTest("Test JSON API 1", 1, function() { 
    $.getJSON("http://test.com/json", function(data) { 
     equals(data.expected, "what you expected", "Found it"); 
    }); 
}); 
0

Da es keine Antwort werde ich in meinen zwei Cent setzen

Wenn das Problem ist, dass Sie mit wechselnden Anforderungen aus dem Back-End zu tun dann, was Sie. Sie müssen sich von diesen Änderungen isolieren. Setzen Sie eine Abstraktion zwischen Front-End und Back-End.

Vielleicht können Sie diese Abstraktion JSON Data Format Interchange nennen.

Also, wenn GUI-Unit-Tests (hoffentlich sind Sie TDDing Ihre Web-GUI) haben Sie eine Mock für die JSON DIF. SO, wenn die Zeit für die Integration der Back-End mit dem Front-End *, Software-Änderungen werden in der Abstraktionsschicht Implementierung durchgeführt werden. Und natürlich haben Sie bereits Tests für diejenigen, die auf der vereinbarten JSON-Struktur basieren.

OBTW, ich denke, dass das serverseitige Team Verantwortung für die Angabe des Protokolls gegen den Server übernehmen sollte.

* Warum erinnert das an den Witz, mein Hintern und dein Gesicht könnten Zwillinge sein.

0

https://github.com/skyscreamer/JSONassert kann bei der Eliminierung von Fehlalarmen hilfreich sein. Wenn die Reihenfolge der vom Server zurückgegebenen Felder sich ändert, die Gesamtantwort jedoch gleich ist, wird kein Fehler ausgelöst.