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