GUI-Testing mit Sikuli - HowTo

[neo4a]

Unit-Testing mit DUnit macht ja nun jeder. Man kann wohl damit auch irgendwie GUI-Elemente testen.

Sikuli bietet da einen etwas anderen Ansatz. Durch einen simplen formalen Aufbau realisiere ich daraus einen GUI-Test:

Zuerst einmal ein typisches Script (testA.sikuli), das einige Aktionen in der Delphi-App ausführt:

Code:

from sikuli.Sikuli import *
def testRun(self):
  switchApp("MyDelphiApp")
  wait(1)
  type(Key.F12)
  wait(1)
  if not exists( ):
    click( )
  click( )
  click( )
  doubleClick( )
  type(Key.F12)
  assert exists( )

#testRun(0)

Bemerkungen:
- Die erste Zeile ist notwendig, damit das Script dann im Batch-Modus funktioniert.
- Def XXX()- ist die Funktionsdeklaration
- Wait()-Aufrufe sind dann sinnvoll, wenn z.B. animierte Übergänge erfolgen.
- Die Einrückungen entsprechen Begin/Ende-Strukturen.
- Assert ist die visuelle Prüfung, ob auf dem Screen auch das da ist, was erwartet wird.
- Die letzte Zeile erlaubt den Aufruf des Scripts in der Sikuli-IDE.

Nachdem ein oder mehrere GUI-Test-Scripts vorliegen, sollte das nun auch im Batch-Modus erfolgen. Dazu dient diese Script, das nacheinander alle Test-Scripts aufruft.

Code:

def setUp(self):
  myScriptPath="C:\\MyPath\\To\\Sikuli"
  if not myScriptPath in sys.path: sys.path.append(myScriptPath)
  
def tearDown(self):
  closeApp("MyApp")

def testA(self):
  import testA
  testA.testRun(0)
  
def testB(self):
  import testB
  testB.testRun(0)

Bemerkungen:
- Dieser Aufbau geht davon aus, dass die Test-Scripts in den myScriptPath abgelegt wurden und dort als Verzeichnisse TestA.sikuli und TestB.sikuli existieren.
- Die formale Struktur des Batch-Scripts lässt sich nun sehr einfach erweitern und variieren. Der Screenshot im Anhang zeigt beispielhaft das Ergebnis eines solchen Tests.

Hinweise:
- Sikuli arbeitet nur mit der GUI, keine API o.ä.
- MyDelphiApp sollte zum Testen für Sikuli wieder erkennbar sein, d.h. SetBounds, Skinning etc. muss dem Zustand entsprechen, womit die TestScripts erzeugt wurden.
- Meine Delphi-Apps werten dazu eine Start-Parameter aus, der das sicherstellt.

Probleme:
- Sikuli verhält sich bei mir manchmal etwas "zickig" und ist auch nicht sehr schnell, was ich aber auf die verwendete Auflösung (2 x 1920 x 1200) schiebe.
- Der Batch-Modus muss noch über die Sikuli-IDE angeschoben werden. Ich habe bislang noch keinen anderen Weg gefunden.

Diese GUI-Tests sind für mich eine sehr hilfreiche Ergänzung zu den Unit-Tests und sicher den Aufwand für die Erstellung wert.

[sx2008]

Seltsam: die Scriptsprache sieht ganz stark nach Python aus, während das Java Runtime Enviroment als Vorrausetzung benötigt wird (also wohl in Java programmiert wurde).

Das ist schon ein bisschen schizo :-D
So nach dem Motto: "Menno, Python gefällt mir eigentlich viel besser, aber ich hab' nur Java an der Uni gelernt"
Aber Python ist als Scriptsprache recht gut geeignet

[neo4a]

Zitat:

Zitat von sx2008 (Beitrag 1114865)

Seltsam: die Scriptsprache sieht ganz stark nach Python aus, während das Java Runtime Enviroment als Vorrausetzung benötigt wird (also wohl in Java programmiert wurde).

Das ist richtig und zukunftssicher, denn damit ist auch gewährleistet, dass die XE2-Programme unter OSX ebenfalls mit diesem Tool getestet werden können.

Die Einarbeitung in Sikuli ist ansich trivial. Mit meinen Beitrag wollte ich lediglich zeigen, wie man damit auch ein ganzes GUI-Test-Framework aufbaut. Das kommt aus den ganzen Docs, Tuts und Samples auf der Website nicht so richtig heraus.