Testen von Microservices
Erfahrungsbericht und Umfrage
David Faragó, EclipseSource & QPR
Dehla Sokenou, GEBIT Solutions GmbH
Microservices
Architekturprinzip für Software
Kleine, unabhängig Einheiten, die Daten und Services kapseln
● Klare Entkopplung
● Auch keine indirekte Kopplung, bspw. über gemeinsam verwendete
Datenbankobjekte
● Ein Microservice = eine (möglichst kleine) Aufgabe
Kommunikation ausschließlich über sprachunabhängige Schnittstellen
Do one thing and do it well.
Klassische Systeme vs. Microservices
Quelle: Kristijan Arsov. What Are Microservices, Actually? https://dzone.com/articles/what-are-microservices-actually
Microservices – Umfeld
DevOps
Container
Cloud
Microservices – Eine kurze Bilanz
Vorteile
● Klare Verantwortlichkeiten für Schnittstellen und Daten
● Unabhängige Releasezyklen und Deployment
● Unabhängige Teams
Herausforderungen
● Integration der vielen verschiedenen Microservices
● Einheitlichkeit, z.B. in Bezug auf die Benutzerschnittstelle
● Testen?
Microservices Pro & Contra aus Testersicht
Aspekt Pro Contra
Team Jeder MS kann von anderen
Teams getestet werden
Verantwortlichkeit für das
Gesamtsystem?
Software Kleinere unabhängige
Einheiten
Verknüpfung der MS
zusätzliche Komplexität
Verteilung Neben Fehlervermeidung
auch Recovery (MTBF & MTTR)
Schwieriges Testumfeld
durch ständige Änderung
Umgebung Replikation der Umgebung
für Testzwecke
Umgebung komplex
Aspekt Pro Contra
Team Jeder MS kann von anderen
Teams getestet werden
Verantwortlichkeit für das
Gesamtsystem?
Software Kleinere unabhängige
Einheiten
Verknüpfung der MS
zusätzliche Komplexität
Verteilung Schwieriges Testumfeld
durch ständige Änderung
Umgebung Replikation der Umgebung
für Testzwecke
Umgebung komplex
Microservices Pro & Contra aus Testersicht
Umfrage:
Kommen Sie in Berührung mit der
Entwicklung von Microservices?
Software-Fehlerklassifizierung
Die weitaus meisten Fehler sind nicht funktionaler Art!
Software-Fehlerklassifizierung
Umfrage:
In welche Klassen
fallen Ihre Fehler?
Teststufen gestern
Test-Pyramide
Teststufen heute
Test-Hut
Teststufen morgen
Erweiterte Test-
Pyramide
Teststufen und Werkzeuge
xUnit
AssertJ
Mocking-Frameworks
Hoverfly Arquillian
testcontainers.org
PACT
REST-assured
Moco
Pretender
mountebank
Cukes in Space!
Selenium
Arquillian Cube Observatiliby-Tools
Serenity BDD
Po
stm
an
Cucumber
Teststufen und Werkzeuge
Umfrage:
Wieviel Prozent testen Sie
auf jeder Teststufe?
Twelve-Factor-App
# Factor Description
I Codebase There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
II Dependencies All dependencies should be declared, with no implicit reliance on system tools or libraries.
III Config Configuration that varies between deployments should be stored in the environment.
IV Backing services All backing services are treated as attached resources and attached and detached by the execution environment.
V Build, release, run The delivery pipeline should strictly consist of build, release, run.
VI Processes Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
VII Port binding Self-contained services should make themselves available to other services by specified ports.
VIII Concurrency Concurrency is advocated by scaling individual processes.
IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system.
X Dev/Prod parity All environments should be as similar as possible.
XI Logs Applications should produce logs as event streams and leave the execution environment to aggregate.
XII Admin Processes Any needed admin tasks should be kept in source control and packaged with the application.
Twelve-Factor-App
# Factor Description
I Codebase There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
II Dependencies All dependencies should be declared, with no implicit reliance on system tools or libraries.
III Config Configuration that varies between deployments should be stored in the environment.
IV Backing services All backing services are treated as attached resources and attached and detached by the execution environment.
V Build, release, run The delivery pipeline should strictly consist of build, release, run.
VI Processes Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
VII Port binding Self-contained services should make themselves available to other services by specified ports.
VIII Concurrency Concurrency is advocated by scaling individual processes.
IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system.
X Dev/Prod parity All environments should be as similar as possible.
XI Logs Applications should produce logs as event streams and leave the execution environment to aggregate.
XII Admin Processes Any needed admin tasks should be kept in source control and packaged with the application.
Umfrage:
Wie wichtig ist für Sie
Dev/Prod-Parity?
Teststufen morgen (2)
so niedrig wie möglich (Shift Left)
Test-Rechteck
Staging
Green/Blue bzw. Red/Black-Deployment
Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more.
https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Staging
Green/Blue bzw. Red/Black-Deployment
Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more.
https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Staging
Canary-Deployment
Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more.
https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Staging
Canary-Deployment
Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more.
https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Testtreiber
Testtreiber
FAULT INJECTION
CHAOS MONKEY TESTING
Testtreiber
FAULT INJECTION
Observability / Fehleranalyse
ELK-Stack
Leichtgewichtige Alternative: Graylog & Grafana
LOG
Process Store Visualize
Observability / Fehleranalyse
ELK-Stack
Leichtgewichtige Alternative: Graylog & Grafana
LOG
Process Store Visualize
Umfrage:
Verwenden Sie
Observability/Monitoring?
Fazit
Dev/Prod-Parity
Shift left
(niedrigere Teststufe)
möglich?
Diskussion und Fragen
Umfrage:
Wieviel Prozent testen Sie
auf jeder Teststufe?
Umfrage:
In welche Klassen
fallen Ihre Fehler? Umfrage:
Kommen Sie in Berührung mit der
Entwicklung von Microservices?
Umfrage:
Wie wichtig ist für Sie
Dev/Prod-Parity? Umfrage:
Verwenden Sie
Observability/Monitoring?