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.Gibt es eine Möglichkeit, einen "API-Vertrag" durchzusetzen, wenn ich die API und die Benutzeroberfläche meiner Web-App separat teste?
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?
wir haben die gleiche Frage.Und schließlich beschließen wir, nur Unit-Tests im Ember-Test zu behalten (und die gesamte Logik mit dem Store in Services zu verschieben, Unit-Tests viel einfacher zu machen und Skip-Trugbild zuzulassen) und Integrationstests mit Selen hinzuzufügen (nightwatch.js oder etwas anderes). Von unserem Vorschlag gab es creon cronjob, der reales API anfordert und Antworten in Fata Morgana speichert, aber es sieht hässlich aus. –