Gibt es eine Möglichkeit, einen "API-Vertrag" durchzusetzen, wenn ich die API und die Benutzeroberfläche meiner Web-App separat teste?

Question

Ich entwickle eine Ember.js App mit einer Phoenix API. Ich habe den Ratschlag von jemandem befolgt, die Benutzeroberfläche und die API als separate Projekte zu behalten, und ich weiß, dass ich ember-cli-mirage verwenden kann, um meine API während der Entwicklung und Tests zu verspotten. Aber das macht mich wirklich nervös. Ich bin es gewohnt, eine Reihe von Integrationstests zu haben, die die Benutzeroberfläche und die API zusammen testen. Ich weiß mit Sicherheit, dass eines Tages ein anderer Entwickler eine bahnbrechende Veränderung in einem der Projekte vornehmen wird, und wir werden es erst bemerken, wenn sich die Nutzer beschweren.

Auf der anderen Seite mag ich die Idee, die API in dem Client zu verspotten, wo Ember.js läuft. Es sollte die Entwicklung und das Testen wirklich schnell machen.

Gibt es eine Möglichkeit, eine High-Level-Beschreibung meiner API-Endpunkte zu extrahieren und diese als Plausibilitätsprüfung zu verwenden, um sicherzustellen, dass meine verspottete API alle Anforderungen erfüllt? Wenn ich beispielsweise eine Route auf meinem API-Server hinzufüge oder entferne, möchte ich, dass meine Ember.js-Tests sofort fehlschlagen, wenn die verspottete API diesen Änderungen nicht entspricht. Weil ich weiß, dass dies eines Tages passieren wird. Es ist besonders bedenklich, wenn ich eine kontinuierliche Bereitstellung nach erfolgreichen Builds verwenden möchte.

Oder sollte ich nur einen echten API-Server auf dem CI-Rechner starten und meine Tests dagegen ausführen?

Ich mag die Idee, einen API-Vertrag zu erzwingen. Ich könnte das Prinzip auch in zukünftigen Mobil- oder Desktop-Apps wiederverwenden. Sie erhalten eine gewisse Konsistenz, ohne eine Menge Abhängigkeiten zu installieren und eine echte API zu erstellen.

Eine andere Idee: Vielleicht schreibe ich eine Reihe von API-Akzeptanztests, aber führe sie gegen die echte und die verspottete API. Und dann könnte ich den verspotteten API-Code (ember-cli-mirage) in meinen Haupt-API-Repo einfügen und ihn als Submodul in das Ember.js-Repo einbinden.

Wie nähern sich die Menschen derzeit diesem Problem?

Answer 1

Ihre Ember-Tests sollten sich auf das Verhalten der Clientanwendung selbst konzentrieren, nicht auf die Implementierungsdetails Ihrer API. Während es schwieriger ist, in ember-cli-mirage eine separate mockige Instanz Ihrer API-Logik zu pflegen, sollten Sie in der Realität nur Mirage-Endpunkte und Verhalten hinzufügen, wie es Ihre Ember-Tests erfordern.

Wenn Sie Ihrem API-Server eine Route hinzufügen und kein Ember-Code damit interagiert, sollte kein Ember-Test geschrieben werden, der einen verspotteten Mirage-Endpunkt verwendet.

Wenn Sie eine Route entfernen oder das Verhalten in Ihrer API ändern, ist es sinnvoll, dass alle betroffenen Ember-Tests sofort fehlschlagen, aber das Umschreiben dieser Ember-Tests und Mirage-Endpunkte zur Spiegelung des neuen Verhaltens ist nur mit Kosten verbunden Geschäft.

Es ist mehr Arbeit auf lange Sicht, aber ich denke, Ihre Tests werden sinnvoller sein, wenn Sie die API und Ihre verspotteten Endpunkte in Mirage als separate Probleme behandeln. Deine Ember-Tests sollten nicht testen, ob dein Server funktioniert - sie sollten nur überprüfen, dass dein Ember-Code bei bekannten Einschränkungen funktioniert.

Vielleicht ein Weg Auslassungen in Ihrem Test-Suiten zu vermeiden, ist eine (menschliche) Politik zu erzwingen, wobei jede Änderung des Verhaltens des API ist wie Gherkin in einer formalen Prüfung DSL specced, zumindest die Anforderungen zu dokumentieren, und verwenden Sie dann das als einzige Referenz zum Schreiben der neuen Tests und des Codes, der die Änderungen implementiert.