Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Software-Architekten
Der Begriff „Testbarkeit“ ist in der Praxis oft schwer zu konkretisieren. In dieser Hinsicht ähnelt er der „Qualität“ – man kümmert sich um sie, wenn sie fehlt. Greift man diese Konkretisierung aber an, stellt man fest, dass die meisten Testbarkeits-Anforderungen an die Architektur-Kollegen im Projektteam adressiert sind. Diese Seite sammelt typische Testbarkeits-Themen und erläutert in Form einer Checkliste mit „Do’s & Don’ts“, wie sie seitens Architektur jeweils frühzeitig berücksichtigt werden können.
Das Begriffssystem, sowie die einzelnen Kategorien und Maßnahmen sind im Artikel definiert. Der Artikel ist in zwei Teilen in Objektspektrum erschienen.
Sie können den Artikel hier herunterladen:
Mit Beiträgen von: Jürgen Baier, Christian Brandes, Shota Okujava.
| Ergänzungen & Feedback zur Checkliste bitte an: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! |
Architekturmaßnahmen zur Testbarkeit
| Kontext | Testbarkeits-Anforderung | an | Mögliche Architekturmaßnahmen zur Realisierung | Einhaltung | Zu vermeiden |
| Start-zustand und Vor-bedin-gungen herstellen | Startzustand im SUT erzeugen | SUT | Zustandsmodell definieren Automatisierte Mechanismen zur Zustandserzeugung |
Zustandsmodell pflegen VM für Umgebungskonfigurationen |
Manuelle Bereitstellung von Infrastuktur oder Testdaten |
| Einzelnen Datensatz einspielen | SUT | Schema partitionieren (keine zirkulären Beziehungen) VM-/KM-Werkzeuge auf Schemata anwenden (z.B. Liquibase) Werkzeuggestützte Extraktion zusammenhängender Datensätze (z.B. Jailer) |
Datenstrukturen reviewen 4-Augen-Prinzip bei Schema-Änderungen Werkzeuggestütze Analyse (z.B. aif zirkuläre Beziehungen) |
Fremdschlüssel-beziehungen, die nur im Code abgebildet werden Technisch motivierte Tabellen, die zu komplexen Referenzen führen |
|
| Datensätze duplizieren/ klonen | SUT | Dokumentiertes, in sich konsistentes und abgeschlossenes DB-Schema Einfache, fachlich motivierte Fremdschlüsselbeziehungen |
Code- und Schema-Reviews Mindeststandards für Schema-Dokumentation |
Komplexe Fremdschlüssel-beziehungen berechnete Fremdschlüssel |
|
| Datum und Uhrzeit simulieren | TU | Realisierung der TU-Abstraktionsschicht | statische Code-Analysen (z.B. SonarQube) Architektur- und Code-Reviews |
nur Verwendung von Echtzeit Verwendung der DB-Zeit |
|
| Benutzer und Rechte konfigurieren | TU | Realisierung der TU-Abstraktionsschicht (z.B. für Mock-Fähigkeit) Steuerung der Rechte über Konfiguration |
Code-Analysen Architektur- und Code-Reviews |
Ermitteln der Rechte im Code | |
| Fremd-komponenten konfigurieren | TU | Realisierung der TU-Abstraktionsschicht (z.B. für Mock-Fähigkeit) Schichtarchitektur mit Zugriffsregeln Einhaltung der Architektur-Empfehlungen auch in Fremdkomponenten |
statische Code-Analysen (z.B. SonarQube) Architektur- und Code-Reviews |
Direkte Zugriffe auf Fremd-systeme/Plattformfunktionalität Fremdsysteme, die sich nicht an die Architektur-Empfehlungen halten |
|
| Eingaben ins SUT vor-nehmen | UI-Objekte erkennen und bedienen | SUT | Technologieauswahl Verwendung fachlich eindeutiger und stabiler Identifier Abstimmung mit Testautomatisierern |
Code-Analyse, Code-Review | Einsatz von Technologien mit generierten UIS / generierten (dynamischen) IDS |
| Datenbank befüllen | SUT | Abstrakte und verständliche DB-Schema-Definition Automatisierung der DB-Initialisierung Laufende Pflege der Initialisierungsdaten (RECHTS?) |
Architektur-Review regelmäßige Analyse manueller Tätigkeiten |
Ableiten des DB-Schemas aus der Klassenstruktur manuelle Eingriffe in der DB-Bereitstellung |
|
| Andere Schnitt-stellen befüllen | SUT | Realisierung der TU-Abstraktionsschicht | Code-Analysen Architektur- und Code-Reviews |
Direkte Zugriffe auf Fremd-systeme/Schnittstellen | |
| Ausgaben des SUT prüfen | UI-Objekte erkennen und auslesen | SUT | Technologieauswahl Verwendung fachlich eindeutiger und stabiler Identifier Abstimmung mit Testautomatisierern |
Code-Analyse, Code-Review | Einsatz von Technologien mit generierten UIS / generierten (dynamischen) IDS |
| Datenbank auslesen | SUT | Abstrakte und verständliche DB-Schema-Definition Werkzeugunterstützung |
Architektur-Review regelmäßige Analyse manueller Tätigkeiten |
Ableiten des DB-Schemas aus der Klassenstruktur manuelle Eingriffe in der DB-Bereitstellung |
|
| Log- /Protokoll-Dateien auslesen | SUT | Richtlinien für Log-Level und Log-Ausgaben Einheitliches Logging-Framework und -Format (z.B. log4j) Dokumentation der Log-Level und -Ziele |
Code-Analysen Architektur- und Code-Reviews |
Einsatz unterschiedlicher Frameworks/Formate fehlende Richtlinien Log-Ausgaben verstreut in mehreren Log-Zielen |
|
| Andere Schnittstellen auslesen | SUT | Realisierung der TU-Abstraktionsschicht | Code-Analysen Architektur- und Code-Reviews |
Direkte Zugriffe auf Fremd-systeme/Schnittstellen | |
| Nach-bedin-gungen prüfen | Zustand des SUT auslesen | SUT | Zustandsmodell definieren Automatisierte Mechanismen zur Zustandsabfrage |
Zustandsmodell pflegen | - |
| Fremd-komponenten auslesen | TU | Realisierung der TU-Abstraktionsschicht | Code-Analysen Architektur- und Code-Reviews |
Direkte Zugriffe auf Fremd-systeme/Plattformfunktionalität Fremdsysteme, die sich nicht an die Architektur-Empfehlungen halten |