Seminar Mobly Testarchitektur und Best Practices

Seminarprofil

Wartbarkeit entsteht durch klare Grenzen zwischen Infrastrukturzugriff, fachlicher Aktion und Validierung. Das Seminar überführt typische Anti-Patterns in eine modulare Struktur und verbindet Architekturentscheidungen mit konkreten Mobly-Lebenszyklusregeln.

Didaktische Einordnung: Zwei Tage erlauben die Analyse typischer Strukturprobleme und die praktische Überarbeitung eines repräsentativen Testprojekts. Spezielle Controller- oder Snippet-Entwicklung wird in eigenen Vertiefungen behandelt.

Lernziele

• Testprojekte in klar abgegrenzte technische Schichten zerlegen
• Setup, Aktionen, Validierungen und Cleanup wiederverwendbar gestalten
• Konfiguration und Testdaten kontrolliert verwalten
• Fehlerbilder durch robuste Synchronisation und Assertions reduzieren
• Architekturregeln durch Reviews und automatisierte Prüfungen absichern

Zielgruppe

Erfahrene Testautomatisierer, Python-Entwickler, Testarchitekten und technische Verantwortliche für wachsende Mobly-Projekte.

Voraussetzungen

Gute Python-Grundkenntnisse und praktische Erfahrung mit Mobly-Testklassen, Testbeds und mindestens einem Controller.

Inhaltsübersicht

1. Tag 1 – Bestehende Struktur und Anti-Patterns analysieren
2. Tag 1 – Schichtenmodell für Testprojekte entwerfen
3. Tag 1 – Lebenszyklus und Ressourcen sauber modellieren
4. Tag 2 – Aktionen und Assertions wiederverwendbar machen
5. Tag 2 – Konfiguration und Testdaten strukturieren
6. Tag 2 – Qualitätssicherung und Architekturregeln etablieren

1. Tag 1 – Bestehende Struktur und Anti-Patterns analysieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Überladene Testklassen, globale Zustände und duplizierte Geräteaktionen identifizieren.
2. Schritt 2: Instabile Wartezeiten, verdeckte Abhängigkeiten und unklare Fehlerbehandlung markieren.
3. Schritt 3: Qualitätsziele für Lesbarkeit, Diagnose, Laufzeit und Wiederverwendung festlegen.

2. Tag 1 – Schichtenmodell für Testprojekte entwerfen

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Controllerzugriff, technische Adapter, Domänenaktionen und Tests trennen.
2. Schritt 2: Öffentliche Schnittstellen jeder Schicht definieren.
3. Schritt 3: Abhängigkeiten so ausrichten, dass Testfälle keine Infrastrukturdetails duplizieren.

3. Tag 1 – Lebenszyklus und Ressourcen sauber modellieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Klassenweite von testfallspezifischen Ressourcen unterscheiden.
2. Schritt 2: Setup-Schritte idempotent und Teardown-Schritte fehlertolerant gestalten.
3. Schritt 3: Recovery nur dort einsetzen, wo Ausgangszustände sicher nachweisbar sind.

4. Tag 2 – Aktionen und Assertions wiederverwendbar machen

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Fachliche Aktionen mit klaren Vor- und Nachbedingungen kapseln.
2. Schritt 2: Polling und Ereignisabfragen statt starrer Wartezeiten einsetzen.
3. Schritt 3: Domänenspezifische Assertions mit hilfreichen Diagnosemeldungen entwickeln.

5. Tag 2 – Konfiguration und Testdaten strukturieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Umgebungs-, Geräte-, Produkt- und Testparameter voneinander trennen.
2. Schritt 2: Standardwerte und Pflichtparameter zentral validieren.
3. Schritt 3: Testdaten versionierbar und unabhängig von flüchtigen Laborzuständen halten.

6. Tag 2 – Qualitätssicherung und Architekturregeln etablieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Code-Reviews mit einer Mobly-spezifischen Prüfliste durchführen.
2. Schritt 2: Statische Prüfungen, Unit-nahe Tests und kleine Hardware-Smoke-Tests kombinieren.
3. Schritt 3: Eine Zielstruktur und schrittweise Refactoring-Roadmap für ein Projekt erstellen.

Praxisprojekt

1. Schritt 1: Eine monolithische Testklasse anhand definierter Anti-Patterns bewerten.
2. Schritt 2: Controllerzugriff, Domänenaktion und Assertion in getrennte Module überführen.
3. Schritt 3: Eine starre Wartezeit durch zustandsbasierte Synchronisation ersetzen.
4. Schritt 4: Eine Architektur- und Review-Checkliste auf den überarbeiteten Test anwenden.