Ich habe vor einiger Zeit einen Test geschrieben, der eine Integration testet, die ich zwischen meinem Code und einer API eines Drittanbieters geschrieben habe. Der Test stellt sicher, dass die Integration ordnungsgemäß funktioniert und wir die erwarteten Ergebnisse erhalten.
Der formale Build ist heute fehlgeschlagen, da der Test beim Versuch, eine Verbindung mit der API des Drittanbieters herzustellen, einen 500-Fehler erhalten hat.
Macht es Sinn, eine solche Situation zu testen?
Meiner Meinung nach können Integrationstests fehlschlagen, wenn der Drittanbieter (db, webservice usw.) nicht verfügbar ist. Wenn Sie die Integration selbst und die einfache Funktionalität nicht testen möchten, können Sie das Ergebnis Ihrer API nachahmen und gegen sie testen. In diesem Szenario hängt Ihr Test nicht mehr von der Verfügbarkeit des Drittanbieters ab.
Ich markiere Einheitentests in der Regel abhängig von der Verfügbarkeit eines Drittanbieters mit einem Gruppenattribut wie "Integration" und schließe sie vom kontinuierlichen Integrationsprozess aus. Stattdessen ließ ich sie in einem nächtlichen Build laufen. Integrationstests sind in der Regel teuer und der Punkt der kontinuierlichen Integration ist schnelles Feedback .
Nein, es ist nicht hilfreich für Ihre Testsuite, wenn ein Dienst eines Drittanbieters nicht verfügbar ist. Aber Sie möchten Ihre Integration mit dem Service vollständig testen. Die folgende Strategie hat für mich gut funktioniert:
Isolieren Sie den Dienst eines Drittanbieters in einem Modul (sagen wir eine Klasse, aber Ihre Modularisierung ist in Ordnung), die so wenig wie möglich neben der Kapselung der Verbindung zum Dienst leistet. Schreiben Sie Methoden für die Klasse, damit Sie den Unterschied zwischen Fehlern erkennen können, die der Fehler des Dienstes sind, und Fehlern, die Ihre Schuld sind. Geben Sie beispielsweise Ausnahmebedingungen für Ausnahmen eine gemeinsame Oberklasse an.
Schreiben Sie Einheitentests der Serviceklasse, so dass
Wenn ein Service-Down-Fehler auftritt, werden Tests bestanden, aber der Fehler protokolliert.
Wenn ein anderer Fehler auftritt, scheitern Sie wie üblich.
Schreiben Sie diese Tests so, dass sie gegen den Live-Service laufen. Es sollte eine kleine Anzahl dieser Tests geben, daher sollten sie kein Problem für die Testsuite-Laufzeit verursachen.
Stottern Sie die Serviceklasse aus allen anderen Tests, einschließlich Integrationstests. (Bei "Integrationstests" hier handelt es sich um Tests, die alle Ebenen Ihres eigenen Codes testen, nicht ob sie mit dem Drittanbieter-Dienst interagieren.)
Wenn Sie die Serviceklasse aus Integrationstests stubben oder verspotten, stubsen Sie nicht die öffentliche API der Serviceklasse ab oder machen Sie sich über sie lustig, sondern stümpern oder spielen eine niedrigere Ebene, vielleicht eine interne Methode der Serviceklasse oder der Bibliothek Sie verwenden, um eine Verbindung mit dem Dienst herzustellen. Dies verhindert Integrationsfehler beim Aufruf der Serviceklasse. Testen oder stempeln Sie in Unit-Tests die öffentliche API der Serviceklasse wie jede andere Klasse.
Wie Martin Buberl vorschlägt, könnte es hilfreich sein, einen separaten Testlauf von Integrationstests durchzuführen, bei dem die Serviceklasse nicht abgestempelt oder verspottet wird. Um ehrlich zu sein, das ist etwas, das in mehreren Projekten diskutiert wurde, an denen ich beteiligt war, aber ich glaube nicht, dass es jemals getan wurde. Wenn ein Service eines Drittanbieters fehlschlägt, erfahren wir immer von Produktionsfehlern (berichtet von der Überwachung oder vom Kundensupport), bevor wir es aus Tests erfahren.