Perl-Test-Suite für API

Ich schreibe ein perl-Modul, das mit einer API Schnittstelle und ich möchte eine Test-Suite für es schreiben, bevor es auf CPAN setzen. Da dieses Modul jedoch im Grunde nur eine Schnittstelle für eine API ist, würden alle Tests einen gültigen API-Schlüssel und Benutzer erfordern. Offensichtlich kann ich dieses Modul nicht mit meinem API-Schlüssel und meinem Benutzernamen in der Testsuite veröffentlichen, also was ist der beste Weg, um so etwas zu handhaben? Sollte ich nur lokal testen und dann ohne Tests auf CPAN setzen? Ist jemand schon mal darauf gestoßen und hat eine gute Lösung gefunden? Ich weiß, dass das Schreiben von Tests die beste Vorgehensweise ist, also würde ich es gerne tun, wenn ich kann. Vielen Dank!Perl-Test-Suite für API

Quelle

2013-07-09 srchulo

Sie könnten eine gefälschte API schreiben und bereitstellen, die nicht den Schlüssel oder einen falschen Schlüssel zum Testen des Schlüsselmechanismus benötigt. Dies könnte mit der realen API über eine Umgebungsvariable für Leute, die das echte Ding haben, getauscht werden. – KeepCalmAndCarryOn

@KeepCalmAndCarryOn - siehe meine Antwort :) – DVK

Warum wickeln Sie die API-Aufrufe in kleine Funktionen (z. B. die Funktion tut nichts, aber die API-Aufruf), und dann diese Funktionen in Ihren Tests bei Bedarf mit Test::MockObject oder ähnlichem?

Dies wäre noch besser, wie Sie Tests zu haben, wären in der Lage, die unterschiedlichen Ergebnisse von API testen (Ausfall, Auth Ausfall, etc ...)

Quelle

2013-07-09 21:17:07 DVK

Als Anmerkung: das ist definitiv eine Lösung viel mehr vorzuziehen, "die Tests zu überspringen", aber schlechter als "die Tests für Komponententests 100% von Nicht-API-Anrufcode zu verspotten + die Benutzer ihren eigenen Schlüssel und Benutzer für Integrationstestfälle liefern lassen" – DVK

Diese Antwort ist auch gut. Sie werden die Bits testen, die API-Rückgabewerte ausführen. –

Ich machte in meiner Dokumentation klar, dass mein Modul ohne einen API-Schlüssel nutzlos war, und benutzte skip: {} Konstrukte von Test :: More, um alle Tests zu überspringen, wenn der Schlüssel nicht vorhanden war. Sie können auch "bail_out" wählen, anstatt zu überspringen.

Stellen Sie sicher, dass in Ihren Dokumenten erläutert wird, wie der API-Schlüssel mit dem Modul kommuniziert wird.

Quelle

2013-07-09 21:12:57

können Sie mir den Namen Ihres Moduls sagen, damit ich es als ein Beispiel betrachten kann? – srchulo

ja. Gib mir eine Minute, um nachzusehen. Ich habe nicht in 2 Jahren daran gearbeitet :-) –

https://metacpan.org/release/VendorAPI-2Checkout-Client –

Die übliche Art, wie ich diese Art der Sache handhaben ist benötigen eine Umgebungsvariable, um die Testsuite ausführen zu können. Die Umgebungsvariable enthält das nützliche Informationsbit (z. B. einen API-Schlüssel, einen Hostnamen zum Herstellen einer Verbindung usw.)

Hier ist ein Beispiel dafür, wie Sie diese Art von Problem in einer Testdatei behandeln können. Wir verwenden diese für die MongoDB Verteilung zu überprüfen, ob es ein verfügbarer Server ist laufen gegen:

BEGIN { 
    eval { 
     my $host = exists $ENV{MONGOD} ? $ENV{MONGOD} : 'localhost'; 
     $conn = MongoDB::MongoClient->new(host => $host, ssl => $ENV{MONGO_SSL}); 
    }; 

    if ([email protected]) { 
     plan skip_all => [email protected]; 
     exit 0; 
    } 
};

All dies tut, ist zu versuchen, zu einem Host in dem MONGOD Umgebungsvariable (oder auch localhost.) Angegeben anschließen Wenn es kann Es überspringt alle Tests und sagt warum. Die Überspringungen zählen immer noch als kein Fehler, so dass die Installation des Moduls nicht verhindert wird, wenn kein Testserver verfügbar ist.

Ich habe diesen Code in einer .pm-Datei, die ich use in jeder .t-Datei in der Verteilung.

Quelle

2013-07-09 21:20:48 friedo

das ist auch eine gute Antwort. –

Perl-Test-Suite für API

Antwort

Verwandte Themen