In Kürze werde ich ein Projekt auf Basis von Windows Azure starten. Und ich frage mich, was sind die Erfahrungen mit dem Testen für Windows Azure-Projekte (in kontinuierlicher Integration (mit einem TFS-Build-Server))? (Eventuell mit TDD)
Einige Dinge habe ich mich gefragt:
Thnaks im Voraus!
Es gelten die gleichen bewährten Verfahren zum Schreiben von Komponententests für Anwendungen außerhalb von Windows Azure. Wenn Sie eine externe Abhängigkeit von dem haben, was Sie tatsächlich testen, sollte diese Abhängigkeit für Ihren granularen Komponententest verspottet und injiziert werden.
Wenn ich beispielsweise Windows Azure-Speicherwarteschlangen verwende, habe ich eine Schnittstelle, die ich für die Interaktion mit der Warteschlange selbst verwende. In meinem Code, der den Warteschlangendienst verbraucht, kann ich das Subsystem über die Schnittstelle verspotten und die Abhängigkeitsinjektion verwenden den Mock spritzen. Dies beseitigt die Notwendigkeit, während der Komponententests tatsächlich mit dem Emulator umzugehen. In den meisten Fällen ist die konkrete Implementierung des mit der Warteschlange arbeitenden Codes nicht viel mehr als ein sehr dünner Wrapper.
Ich persönlich schieße nicht auf eine 100% ige Testabdeckung, daher habe ich möglicherweise keine direkten Komponententests, die die konkrete Implementierung der Wrapper nutzen. In vielen Fällen versuche ich, Integrationstests durchzuführen, die diese Wrapper trainieren und mehrere Aspekte des Systems zusammenarbeiten lassen. In einigen Fällen kann ich die Integrationstests im Emulator ausführen (z. B. für Speichervorgänge), in einigen Fällen müssen sie jedoch nur mit Zugriff auf die Windows Azure-Umgebung ausgeführt werden (im Fall der Verwendung von ACS oder Service Bus).
Idealerweise möchten Sie über eine Reihe von Skripts verfügen, die ausgeführt werden können, um eine Mindestanzahl von Testservern in Azure hochzufahren, Ihre Lösung bereitzustellen und Integrationstests durchzuführen, die nicht lokal durchgeführt werden können. Dann holen Sie sich die Ergebnisse und lassen Sie das Skript alles herunterfahren (oder lassen Sie es optional laufen, wenn Sie das brauchen). Führen Sie dann die Integrationstestsuite aus, die diese Skripts oft genug verwendet, um Probleme zu erkennen. Sie müssen diese jedoch nicht jedes Mal ausführen, wenn Sie etwas einchecken, es sei denn, Sie sind mit der Testumgebung ständig vertraut. Wenn Sie mit den Kosten einer semi-permanenten Testumgebung in Azure zurechtkommen, sollten Sie sicherstellen, dass die Skripts für eine Updatebereitstellung und nicht für das Löschen und erneute Bereitstellen geeignet sind, um die Kosten ein wenig zu reduzieren (Einsparungen wären relativ häufig Bereitstellung erfolgt).
Ich glaube, dass diese Frage sehr subjektiv ist, da Sie wahrscheinlich verschiedene Meinungen bekommen werden.
Tags und Links azure unit-testing