© best_vector/Shutterstock.com
Windows Developer
Testing mit Microservices - Herausforderungen beim automatisierten Testen von Cloudlösungen

Kolumne: Stropek as a Service

Wenn ich mit anderen Entwicklungsteams über das Thema automatisiertes Testen diskutiere, stoße ich auf ganz unterschiedliche Meinungen und Vorgehensweisen. Die einen schwören auf End-to-End-Tests, die anderen setzen voll und ganz auf Unit-Tests, und wieder andere finden automatisierte Tests überhaupt überbewertet und verlassen sich auf manuelles Testen, weil Automatisierung zu teuer und unzuverlässig ist.

Rainer Stropek


Unit- vs. Integrations- vs. End-to-End-Tests Der überwiegende Teil der Tests sollten Unit-Tests sein, also Tests, die eine abgegrenzte Programmfunktion automatisiert testen. Abhängigkeiten werden durch Mock-Objekte ersetzt. Ein geringerer Teil sollten Integrationstests sein. Sie testen das Zusammenspiel mehrerer Programmteile, deren Funktion bereits durch Unit-Tests geprüft wurde. Es werden bewusst weniger Mock-Objekte eingesetzt. Bei End-to-End Tests simuliert ein Softwareroboter den Benutzer und bedient automatisiert die vollständige Anwendung über dessen Benutzerschnittstelle. Diese Tests sind aufwendig zu entwickeln und sollten sparsam eingesetzt werden. Der Fokus liegt auf wenigen, zentralen Prozessen, die Benutzer in der Software abarbeiten und deren korrektes Funktionieren besonders wichtig ist.DevOps verlangt keine vollständige Testabdeckung der sehr einfach strukturiert ist und dadurch ein geringes Fehlerrisiko hat, bei dem die Folgekosten eines enthaltenen Fehlers gering sind oder der sich sehr selten ändert,Herausforderung MicroservicesLösungsansatz: ContainerMicrosoft hat diesem Problem in der Azure-Cloud ein eigenes Produkt gewidmet: Azure Dev Spaces. Sie machen es Entwicklerinnen besonders einfach, einen Microservice zu Entwicklungs- und Testzwecken in eine Kubernetes-Umgebung zu deployen, in der die anderen Microservices verfügbar sind. Dadurch reduziert man die Anforderungen an die Leistung und richtige Konfiguration der Entwicklungsumgebung enorm.Wer eine fertige Lösung wie Dev Spaces nicht einsetzen kann oder will, der sollte seine Gesamtlösung so bauen, dass Entwicklerinnen möglichst einfach lokal oder in Testumgebungen laufende Microservices in eine Gesamtumgebung einbinden können. Hier einige Beispiele: Es sollte durch Konfiguration möglich sein, eine Testumgebung so einzustellen, dass ein gewisser Microservice durch eine Test- oder Entwicklungsversion ersetzt werden kann. Das muss beim Erarbeiten des Service-Discovery-Konzepts für die Microservices-Architektur berücksichtigt werden. Lokal, z. B. im Debugger laufende Microservices sind bei HTTP-basierender Kommunikation nicht so einfach in eine Gesamtlösung, die in der Cloud läuft, zu integrieren. Werkzeuge wie ngrok sind in diesem Zusammenhang hilfreich und sollten in Zusammenarbeit mit den Netzwerkteams den Entwicklungsteams zugänglich gemacht werden. Alternativ kann man das lokale Entwicklungsnetzwerk auch mit VLANs in der Cloud (z. B. Azure-VPN-Gateway) verbinden und so eine Ver...

Windows Developer
Testing mit Microservices - Herausforderungen beim automatisierten Testen von Cloudlösungen

Kolumne: Stropek as a Service

Wenn ich mit anderen Entwicklungsteams über das Thema automatisiertes Testen diskutiere, stoße ich auf ganz unterschiedliche Meinungen und Vorgehensweisen. Die einen schwören auf End-to-End-Tests, die anderen setzen voll und ganz auf Unit-Tests, und wieder andere finden automatisierte Tests überhaupt überbewertet und verlassen sich auf manuelles Testen, weil Automatisierung zu teuer und unzuverlässig ist.

Rainer Stropek


Unit- vs. Integrations- vs. End-to-End-Tests Der überwiegende Teil der Tests sollten Unit-Tests sein, also Tests, die eine abgegrenzte Programmfunktion automatisiert testen. Abhängigkeiten werden durch Mock-Objekte ersetzt. Ein geringerer Teil sollten Integrationstests sein. Sie testen das Zusammenspiel mehrerer Programmteile, deren Funktion bereits durch Unit-Tests geprüft wurde. Es werden bewusst weniger Mock-Objekte eingesetzt. Bei End-to-End Tests simuliert ein Softwareroboter den Benutzer und bedient automatisiert die vollständige Anwendung über dessen Benutzerschnittstelle. Diese Tests sind aufwendig zu entwickeln und sollten sparsam eingesetzt werden. Der Fokus liegt auf wenigen, zentralen Prozessen, die Benutzer in der Software abarbeiten und deren korrektes Funktionieren besonders wichtig ist.DevOps verlangt keine vollständige Testabdeckung der sehr einfach strukturiert ist und dadurch ein geringes Fehlerrisiko hat, bei dem die Folgekosten eines enthaltenen Fehlers gering sind oder der sich sehr selten ändert,Herausforderung MicroservicesLösungsansatz: ContainerMicrosoft hat diesem Problem in der Azure-Cloud ein eigenes Produkt gewidmet: Azure Dev Spaces. Sie machen es Entwicklerinnen besonders einfach, einen Microservice zu Entwicklungs- und Testzwecken in eine Kubernetes-Umgebung zu deployen, in der die anderen Microservices verfügbar sind. Dadurch reduziert man die Anforderungen an die Leistung und richtige Konfiguration der Entwicklungsumgebung enorm.Wer eine fertige Lösung wie Dev Spaces nicht einsetzen kann oder will, der sollte seine Gesamtlösung so bauen, dass Entwicklerinnen möglichst einfach lokal oder in Testumgebungen laufende Microservices in eine Gesamtumgebung einbinden können. Hier einige Beispiele: Es sollte durch Konfiguration möglich sein, eine Testumgebung so einzustellen, dass ein gewisser Microservice durch eine Test- oder Entwicklungsversion ersetzt werden kann. Das muss beim Erarbeiten des Service-Discovery-Konzepts für die Microservices-Architektur berücksichtigt werden. Lokal, z. B. im Debugger laufende Microservices sind bei HTTP-basierender Kommunikation nicht so einfach in eine Gesamtlösung, die in der Cloud läuft, zu integrieren. Werkzeuge wie ngrok sind in diesem Zusammenhang hilfreich und sollten in Zusammenarbeit mit den Netzwerkteams den Entwicklungsteams zugänglich gemacht werden. Alternativ kann man das lokale Entwicklungsnetzwerk auch mit VLANs in der Cloud (z. B. Azure-VPN-Gateway) verbinden und so eine Ver...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang