0

Also habe ich einen REST-API-Microservice gebaut, der eine lokale Elasticsearch-Instanz abfragt und die Ergebnisse nach einem internen Protokoll übersetzt. Ich habe es in ein Docker-Image eingebaut und würde gerne einige Unit-Tests in Build ausführen. Da ES mit einem privaten Docker-Netzwerk verbunden ist, ist es während des Builds vom Microservice nicht erreichbar, so dass die Tests offensichtlich fehlschlagen. Ich habe mich gefragt, gibt es einen Weg um diese Situation zu umgehen, ohne ein kompliziertes Test-Framework zu verwenden, um Dependency-Injection durchzuführen? Wie testen Sie diese Art von Behältern in Ihrer Arbeitspraxis?Testen von Container-Microservice mit externer Abhängigkeit

+0

Wenn sie über Systemgrenzen hinweg getestet werden, sind sie keine Einheitstests. –

+0

Ja, ich habe später herausgefunden, dass ich den Titel fixiere. –

Antwort

0

Ich würde die Anwendung ohne irgendwelche Tests bauen. Dann würde ich es mit docker run testen, so dass Sie die Vorteile des Dockers Netzwerk nehmen können.

Grob ist dies eleganter als Test in der Mitte des Build:

  1. docker build -t my_app:1.0-early Ihre Anwendung, um ein Bild zu erhalten.
  2. docker run --network my_test_network my_app:1.0-early /run_test_cases.sh. Geben Sie den ordnungsgemäßen Exit-Code oder Text zurück.
  3. Je nach Erfolg oder nicht des Tests wieder tag: docker tag my_app:1.0

Sie haben müssen bereits eine Docker Netzwerk (docker network create my_test_network) oder eine bessere Nutzung Docker-compose.

+0

Aber das bedeutet, dass ich die Tests noch selbst ausführen muss und die Docker-Umgebung durcheinander bringen muss, anstatt die Tests beim Build auszulösen, ohne separate Container für den Test zu erstellen –

+0

Es hängt davon ab, was du mit "mir selbst" meinst. Es kann ein Skript sein. Denke, dass Docker Build am Ende des Tages einen neuen Container für jede Ebene erstellt. Wenn Sie ein CI-System (gitlab, jenkins, bamboo, bitbucket pipeline, etc.) verwenden, können Sie die Build-Phase von der Testphase trennen. – Robert