Was ist die empfohlene Methode zum Testen einer JSON-Client-Server-API?

Question

Edit # 2: Hat jemand eine gute Methode zum Testen der "Mitte" einer Client-Server-Anwendung, wo wir Anfragen und Antworten abfangen, den Client oder Server nach Bedarf fälschen können, und die Selbst-Dokumentation der API bietet?

Gurke könnte in vielen Fällen eine gute Lösung sein, aber es ist nicht ganz das, wonach ich suche. Und diese mittlere Schicht sollte unabhängig von Client/Server-Implementierung sein. (z. B. Black-Box).

---

Unser Client-Server-Modell ist ein Rubin-on-Rails-Server mit einem Flex-Client, eine RESTish Schnittstelle mit JSON als Datenformat. Alles, was der Client auf dem Server veröffentlicht, ist normalerweise ein einzelner JSON-Parameter. Der Server macht seine Sache und antwortet mit einem reinen JSON-Modell.

Wir haben Standard-Rails auf dem Server getestet und wir arbeiten daran, korrekte FlexUnit-Tests auf dem Client durchzuführen (es ist ein bewegliches Ziel). Allerdings gibt es in meinem Team eine Debatte über die Wirksamkeit des aktuellen Testmodells, da jede Änderung auf dem Server einen Teil der API zu brechen scheint. Dies sagt mir, dass es sowohl ein Problem mit der API-Kommunikation (zwischen Teammitgliedern, Selbstdokumentation in Code usw.) als auch einen Mangel an korrekten API-Vernunfttests gibt.

Also habe ich gefragt, ob wir einen Mock-Client zum Testen des Servers auf einer reinen JSON-Ebene (ohne all die anderen Komplexitäten eines Rich-Client) und möglicherweise einen Mock-Server für die gleiche Sache haben müssen mit dem reichen Kunden. Dies würde zwei Zwecken dienen, um die API zu dokumentieren und ein gründlicheres Testen der API selbst zu ermöglichen.

Der Grund, warum es eine Debatte gibt, ist, dass der Rails-Typ behauptet, dass der Integrationstest für die Schienen ausreicht, um alle Serveranforderungen zu testen, und die Testumgebung in der Mitte einfach überflüssig wäre.

Die Frage hier ist, angesichts unserer Situation, wie sollte über die Selbstdokumentation der API gehen, und wie sollten wir die API selbst testen?

EDIT:

Wir haben Routen wie /foo/444/bar.js, aber die Parameter können praktisch beliebig komplexe JSON-String auf die Aktion abhängig, zB:

json={ 
    "foo":{ 
    "x":1, 
    "y":2 
    }, 
    "bar":[1,2,3,4,5] 
} 

aber neben manuell -edited API docs, es gibt keine Selbstdokumentation. Der Schienen-Controller deserialisiert oft Änderungen und wendet diese direkt auf das Modell an. Wäre schön, gemeinsame Tests zu haben, um uns zu sagen, wenn es geändert wird, und, was erwartet wird.

Answer 1

Ich habe gerade begonnen, diese Web-Funktion Test-Tool namens Maxq zu betrachten und ich denke, es hat das Potenzial, Ihr Problem zu lösen, fungiert Maxq als Proxy-Server zwischen Ihrem Web-Client und Server-Anwendung. Es befindet sich auf der Oberseite von Junit, was bedeutet, dass Sie eine ordnungsgemäße Komponententestung für Ihre API durchführen können, indem Sie das Verhalten und die Antworten der Aufrufe Ihrer Server-App bestätigen. Im Prinzip erfasst und protokolliert es alle Anforderungen, die Sie von einem Webclient stellen, und die Antworten, die Sie von einem Server erhalten. Es kann auch Testskripts Ihrer Anfrage generieren, die Sie zum Abspielen und Testen auf einem beliebigen Server verwenden können.

Sie sollten es ausprobieren http://maxq.tigris.org/

Answer 2

Sie können es sich als zwei verschiedene Projekte vorstellen. Wenn Sie zwei Projekte hätten, hätten Sie zwei separate Testsuites geschrieben, oder?

Sie sollten mit dem Aufbau der API zwischen dem Server und dem Client beginnen - als ob Sie keine Kommunikation zwischen den Teams haben, nachdem Sie die Implementierung gestartet haben.

Dann bauen Sie den Client, der die API und einen Server verbrauchen, die die API (oder die Tests zuerst, wenn Sie TDD).

Zum Testen benötigt ein Team einen Mock-Server, um gefälschte API-Antworten zu liefern, um den Client zu testen, und das andere Team muss die produzierten Daten des Servers testen (d.e, das zweite Team benutzt ails Integrationstests wie Ihr Rails guy behauptet)

Answer 3

Ich würde Cucumber empfehlen. Sie können spezifische Tests für Ihre Anwendung schreiben, indem Sie einen Browser emulieren. Auf diese Weise können Sie problemlos Anfragen senden und die JSON-Antwort validieren.

Answer 4

Eine Möglichkeit, dies zu tun Controller Tests verwendet rspec (Sie können auch testen können :: Einheit)

describe PersonApiController 
    # GET /person/1.json 
    it "should respond with a person" do 
    person = Person.create(:name => "scott") 
    get :show, :id => person.id, :format => 'json' 
    response.should be_success 
    response.body.should have_selector('name', :content => person.name) 
    end 
end