Hinzufügen von negativen Tests zu meiner dredd/hook CircleCI Testsuite (API Dokument auf Imkerei), Relevant? Andere Werkzeuge?

Question

Wir verwenden Dredd, um unsere API zu testen, und haben Python-Hooks benutzt, um das API-Dokument erfolgreich zu trennen, und wie auch immer dredd es von der restlichen Testlogik benutzt.

Meine Frage ist: ist es möglich, negative Tests in unseren Workflow zu integrieren? Wenn ja, was wäre die effizienteste Methode/Werkzeug dafür?

Einige Beispiele verdeutlichen:

1. Wir haben ein Zeichen, in dem überprüft die 200-Antwort für, wenn der Benutzer die richtigen Anmeldeinformationen eingibt (Benutzername, Passwort). Wir möchten aber auch einen Test für falsche Anmeldeinformationen hinzufügen, der auch ausgeführt wird, wenn der Befehl "dredd" ausgeführt wird. Dazu müssen wir die Anmeldeanforderung zweimal ausführen - einmal für korrekte und einmal für falsche Anmeldedaten.

Das Problem: - zur Zeit wir nicht wissen, wie jede Anfrage mehr laufen als einmal mit anderen Logik für jede Ausführung

1. Wir haben ein get Benutzerprofil Details, die einmal am Anfang der Testsuite (direkt nach der Erstellung) und einmal nach Ausführung aller anderen Requests ausgeführt werden sollen (Messwerte hinzufügen, Gruppe beitreten/verlassen usw.).

Das Problem: - zur Zeit wir nicht wissen, wie jede Anfrage mehr läuft als einmal mit anderer Logik für jede Ausführung

Die Frage ist einfach, ich bin sicher, es muss eine Möglichkeit vorhanden sein tu dies - aber es wäre auch hilfreich zu wissen, ob wir die Antwort an der richtigen Stelle suchen ... ist das richtige Werkzeug für diese Art von Aufgabe dredd?

Answer 1

API Blueprint unterstützt die Angabe mehrerer Anforderungen und Antworten (Viele-zu-Viele). Folgende Struktur ist eine gültige API Blueprint Aktion:

# POST [/something] 

+ Request (application/json) 
+ Request (application/xml) 
+ Response 200 
+ Response 500 

+ Request (text/plain) 
+ Response 415 
+ Response 500 

Dredd hat eine Unterstützung für diese, wenn auch begrenzt. You need to have them as request-response pairs:

# POST [/something] 

+ Request (application/json) 
+ Response 200 

+ Request (application/json) 
+ Response 500 

Wenn Sie Dokumentation aus der gleichen API Blueprint erzeugen, rate ich Ihnen, es in zwei Dokumente aufgeteilt. Der erste mit positiven Szenarien, der getestet und den Benutzern präsentiert werden soll, und der zweite mit negativen Szenarien, um nur getestet zu werden. Auf diese Weise können Sie Ihre Dokumentation weiterhin lesbar halten.