Seminar Custom Controller für Hardware und Dienste in Mobly

Seminarprofil

Eigene Controller integrieren Laborgeräte, Netzwerkkomponenten, Backend-Dienste oder Simulatoren als gleichwertige Bestandteile eines Testbeds. Ziel ist eine klare, wartbare Grenze zwischen Testlogik und Gerätezugriff.

Didaktische Einordnung: Drei Tage sind erforderlich, um die Controller-Schnittstelle zu verstehen, einen produktionsnahen Treiber zu implementieren und Robustheit, Paketierung sowie Zusammenspiel mit anderen Controllern zu erproben.

Lernziele

• Controller-Vertrag und Lebenszyklus korrekt implementieren
• Konfigurationsdaten validieren und in Geräteobjekte überführen
• Treiber, Transport und Test-API sauber voneinander trennen
• Fehler, Logging und Cleanup für reale Laborsituationen absichern
• Controller paketieren, testen und in Mehrgeräte-Tests einsetzen

Zielgruppe

Python-Entwickler, Testframework-Entwickler, Laborautomatisierer und Embedded-Systemtester.

Voraussetzungen

Gute Python-Kenntnisse, Mobly-Grundlagen und Erfahrung mit der anzubindenden Hardware oder Dienstschnittstelle.

Inhaltsübersicht

1. Tag 1 – Controller-Verantwortung und API entwerfen
2. Tag 1 – Konfigurationsschema und Validierung aufbauen
3. Tag 1 – create, destroy und get_info implementieren
4. Tag 2 – Transport und Treiber abstrahieren
5. Tag 2 – Logging und Diagnose integrieren
6. Tag 2 – Robustheit und Cleanup absichern
7. Tag 3 – Simulatoren, Fakes und Komponententests
8. Tag 3 – Mehrere Controller orchestrieren
9. Tag 3 – Paketierung und Teamnutzung vorbereiten

1. Tag 1 – Controller-Verantwortung und API entwerfen

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

1. Schritt 1: Zu steuernde Ressourcen und fachliche Aktionen inventarisieren.
2. Schritt 2: Öffentliche Test-API von Transport- und Treiberdetails abgrenzen.
3. Schritt 3: Objektidentität, Rollen und Metadaten für das Testbed festlegen.

2. Tag 1 – Konfigurationsschema und Validierung aufbauen

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

1. Schritt 1: Pflicht- und optionale Felder für ein Geräteobjekt definieren.
2. Schritt 2: Typen, Wertebereiche und eindeutige Bezeichner prüfen.
3. Schritt 3: Fehlermeldungen mit Bezug zum betroffenen Konfigurationseintrag erzeugen.

3. Tag 1 – create, destroy und get_info implementieren

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

1. Schritt 1: Konfigurationen in nutzbare Controller-Objekte überführen.
2. Schritt 2: Ressourcenaufbau mit klarer Fehlerbehandlung kapseln.
3. Schritt 3: Bereinigung und Metadatenabfrage vollständig implementieren.

4. Tag 2 – Transport und Treiber abstrahieren

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

1. Schritt 1: Verbindungsaufbau, Authentisierung und Wiederverbindung kapseln.
2. Schritt 2: Kommandos mit Timeout, Rückgabewert und Fehlerklasse versehen.
3. Schritt 3: Treiberaktionen durch eine testfreundliche Domänen-API bereitstellen.

5. Tag 2 – Logging und Diagnose integrieren

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

1. Schritt 1: Controller-spezifische Logpräfixe und Gerätekennungen verwenden.
2. Schritt 2: Rohantworten und relevante Zustandsdaten kontrolliert sichern.
3. Schritt 3: Diagnoseinformationen in Fehler-Hooks und Ergebnisartefakte einbinden.

6. Tag 2 – Robustheit und Cleanup absichern

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

1. Schritt 1: Teilweise Initialisierung und fehlgeschlagene Verbindungen behandeln.
2. Schritt 2: Destroy-Aufrufe idempotent und fehlertolerant gestalten.
3. Schritt 3: Recovery nach Neustart, Timeout oder Verbindungswechsel testen.

7. Tag 3 – Simulatoren, Fakes und Komponententests

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

1. Schritt 1: Transportzugriffe über injizierbare Schnittstellen austauschbar machen.
2. Schritt 2: Konfigurations- und Fehlerfälle ohne reale Hardware testen.
3. Schritt 3: Vertragstests für reale und simulierte Implementierungen definieren.

8. Tag 3 – Mehrere Controller orchestrieren

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

1. Schritt 1: Abhängigkeiten zwischen Geräten, Diensten und Messmitteln modellieren.
2. Schritt 2: Initialisierungsreihenfolge und gemeinsame Cleanup-Regeln festlegen.
3. Schritt 3: Einen End-to-End-Test mit mindestens zwei Controller-Typen ausführen.

9. Tag 3 – Paketierung und Teamnutzung vorbereiten

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

1. Schritt 1: Modulstruktur, Abhängigkeiten und Versionsstrategie festlegen.
2. Schritt 2: Beispielkonfigurationen und API-Nutzung intern dokumentieren.
3. Schritt 3: Freigabeprüfungen für Kompatibilität, Logging und Cleanup automatisieren.

Praxisprojekt

1. Schritt 1: Einen Controller für ein simuliertes Laborgerät entwerfen.
2. Schritt 2: Konfiguration, create, destroy und get_info implementieren.
3. Schritt 3: Timeout und Verbindungsabbruch gezielt testen.
4. Schritt 4: Den Controller gemeinsam mit einem AndroidDevice in einem End-to-End-Test verwenden.