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?