Seminar Poco SDK – Integration in Cocos2d-x- und Cocos-Creator-Projekte

Das Integrationsseminar macht Cocos-Oberflächen durch eine kontrollierte Poco-SDK-Einbindung für strukturierte Testautomation zugänglich.

Inhaltsverzeichnis

1. Seminarprofil
2. Lernziele
3. Schrittweise Lernstrecke
4. Praxisbausteine
5. Zielgruppe und Voraussetzungen
6. Didaktische Einordnung

Seminarprofil

Engine-Version, Sprache, UI-System und Buildziel bestimmen den Integrationsweg. SDK-Dateien, Bindings, Modulregistrierung und Laufzeitdienst werden schrittweise eingebaut. Anschließend werden Szenen, Knoten, dynamische Container und testrelevante Eigenschaften für stabile Selektoren vorbereitet.

Lernziele

• den passenden Cocos-Integrationsweg bestimmen
• Poco-SDK und Bindings schrittweise einbauen
• Laufzeitdienst und Verbindung validieren
• Knoten und Eigenschaften testbar modellieren
• einen Engine-nahen Smoke-Test entwickeln

Schrittweise Lernstrecke

1. Poco-SDK in Cocos-Projekte integrieren

1. Engine-Version, Sprache, Scripting-Variante, UI-System und Buildziel bestimmen den geeigneten SDK-Integrationsweg.
2. SDK-Dateien, Bindings, Modulregistrierungen und Laufzeitdienst werden schrittweise eingebaut und nach jedem Schritt kompiliert.
3. Dynamische Knoten, Szenencontainer und UI-Eigenschaften werden für robuste Selektoren und Wartung dokumentiert.

2. Poco-Hierarchien und robuste Selektoren

1. Elementnamen, Typen, Texte, Eigenschaften, Sichtbarkeit, Position und hierarchische Beziehungen werden systematisch inspiziert.
2. Selektoren bevorzugen stabile Attribute und relationale Bezüge gegenüber langen absoluten Hierarchiepfaden.
3. Mehrdeutige Treffer, dynamische Listen und nicht zugängliche Bereiche werden explizit behandelt und bei Bedarf bildbasiert ergänzt.

3. Geräte- und Anwendungsverbindung

1. Zielsysteme werden mit einer festen Diagnosefolge aus Treiber-, Port-, Berechtigungs-, Prozess- und Netzprüfungen verbunden.
2. Sitzungsaufbau, Anwendungsstart, Statusprüfung und kontrolliertes Beenden werden in wiederverwendbare Hilfsfunktionen überführt.
3. Verbindungsabbrüche werden protokolliert und nur unter klaren Bedingungen automatisch wiederhergestellt.

4. Hybride Game-Tests mit Airtest und Poco

1. Menüs, gerenderte Szenen, Overlays, Ladephasen und Plattformdialoge werden als unterschiedliche Automatisierungsbereiche inventarisiert.
2. Poco bestätigt strukturelle UI-Zustände, während Airtest sichtbare Rendering-Ergebnisse und nicht zugängliche Bereiche prüft.
3. Screen- und Scene-Objekte kapseln Selektoren, Bildvorlagen, Gesten und Übergangslogik für wiederverwendbare Spielabläufe.

5. Python-Testdesign und Wiederverwendung

1. Tests, Screen-Objekte, Plattformadapter, Bildobjekte, Konfiguration und Testdaten werden in klar getrennte Module gegliedert.
2. Globale Zustände und doppelte Klickfolgen werden durch explizite Parameter, Rückgabewerte und fachlich benannte Funktionen ersetzt.
3. Unit- und Integrationstests sichern Hilfsbibliotheken ab, bevor reale Geräte in die Prüfung einbezogen werden.

6. Sicherheit und kontrollierter Betrieb

1. Zugangsdaten, Signiermaterial, Gerätekennungen und sensible Testdaten werden außerhalb des Quellcodes geschützt bereitgestellt.
2. Runner, Testbuilds und Gerätefarm erhalten minimale Berechtigungen und nachvollziehbare administrative Zugriffe.
3. Instrumentierung wird ausschließlich in freigegebenen Testkonfigurationen aktiviert und gegen unerwünschten Netzwerkzugriff begrenzt.

7. Assertions und Qualitätsregeln

1. Technische Vorprüfungen, fachliche Erwartungen und Diagnoseprüfungen erhalten unterschiedliche Assertionstypen.
2. Fehlermeldungen enthalten Szenario, erwartetes Ergebnis, tatsächliche Beobachtung und relevante Kontextdaten.
3. Eine Review-Checkliste prüft Testabsicht, Ausgangszustand, Synchronisation, Selektor, Bildobjekt und Bereinigung.

8. Durchgängiges Praxisprojekt

1. Ein repräsentativer Benutzerweg wird in Ausgangszustand, fachliche Schritte, Kontrollpunkte und Abschlusszustand zerlegt.
2. Die Testsuite wird schrittweise implementiert, auf Varianten ausgeführt und durch absichtlich erzeugte Störungen geprüft.
3. Ergebnisse werden anhand von Stabilität, Verständlichkeit, Laufzeit, Wartbarkeit und Diagnosequalität bewertet und verbessert.

Praxisbausteine

1. Integrationscheckliste für Version und Buildziel
2. SDK-Einbau mit Zwischenkompilierungen
3. Hierarchie- und Eigenschaftsprüfung
4. Smoke-Test über Szenenwechsel und dynamische Knoten

Zielgruppe und Voraussetzungen

Zielgruppe: Cocos-Entwickler, Technical QA, Build Engineers und Testautomatisierer.

Voraussetzungen: Praktische Cocos2d-x- oder Cocos-Creator-Kenntnisse; Zugriff auf Quellcode und Buildumgebung.

Didaktische Einordnung

Drei Tage sind notwendig, weil Integration, Builddiagnose, Laufzeitdienst, UI-Modellierung, Selektorprüfung und ein vollständiger Automatisierungstest eng zusammengehören.

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, geführte Umsetzungsschritte, eigenständige Übungen und kontrollierte Fehlerfälle vertieft. Jeder Praxisblock verwendet definierte Ausgangszustände, überprüfbare Zwischenergebnisse und dokumentierte Diagnoseinformationen.