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 Verantwortlichkeit für das

Teams getestet werden Gesamtsystem?

Software Kleinere unabhängige Verknüpfung der MS

Einheiten zusätzliche Komplexität

Verteilung Neben Fehlervermeidung Schwieriges Testumfeld

auch Recovery (MTBF & MTTR) durch ständige Änderung

Umgebung Replikation der Umgebung Umgebung komplex

für Testzwecke
Microservices Pro & Contra aus Testersicht

Aspekt Pro Contra

Team Jeder MS kann von anderen Verantwortlichkeit für das

Teams getestet werden Gesamtsystem?

Software Kleinere unabhängige Verknüpfung der MS

Einheiten zusätzliche Komplexität
Umfrage:
Verteilung Schwieriges Testumfeld
Kommen Sie in Berührung mit derdurch ständige Änderung
Entwicklung von Microservices?
Umgebung Replikation der Umgebung Umgebung komplex
für Testzwecke
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
Cucumber Observatiliby-Tools
Cukes in Space! Arquillian Cube

Selenium
REST-assured Serenity BDD
Pretender PACT
Moco
mountebank
Hoverfly Arquillian
Postman

testcontainers.org

xUnit Mocking-Frameworks
AssertJ
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.
Umfrage:
VIII Concurrency Concurrency is advocated by scaling individual processes.
Wie wichtig ist für Sie
IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system.
Dev/Prod-Parity?
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.
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
 Testtreiber

FAULT INJECTION

CHAOS MONKEY TESTING

Observability / Fehleranalyse
ELK-Stack

Process Store Visualize

LOG

Leichtgewichtige Alternative: Graylog & Grafana

Observability / Fehleranalyse
ELK-Stack

Process Store Visualize

LOG Umfrage:
Verwenden Sie
Observability/Monitoring?

Leichtgewichtige Alternative: Graylog & Grafana

Fazit

Dev/Prod-Parity

Shift left
(niedrigere Teststufe)
möglich?
Diskussion und Fragen
Umfrage:
In welche Klassen
Umfrage: fallen Ihre Fehler?
Kommen Sie in Berührung mit der
Entwicklung von Microservices?
Umfrage:
Wieviel Prozent testen Sie
auf jeder Teststufe?
Umfrage:
Wie wichtig ist für Sie
Dev/Prod-Parity?
Umfrage:
Verwenden Sie
Observability/Monitoring?