[ Impressum ]

LiveCode TestLib

www.Rozek.de > LiveCode > TestLib
Die "TestLib" ist ein kleiner LiveCode [1] "Library Stack" mit einer Reihe von einfachen Kommandos zur Vereinfachung automatisierter (Unit-)Tests in LiveCode Skripten.

Der Grundgedanke hinter den hier vorgestellten Kommandos ist, dass die formulierten Bedingungen üblicherweise erfüllt sein sollten: schlägt ein Test fehl, so gilt das getestete Programm als fehlerhaft und entweder muss der Test angepasst oder das Programm korrigiert werden.

Anwendungen der "TestLib" sehen meist ungefähr wie folgt aus:

assert_empty the result
assert_beginsWith "InvalidArgument", Signal
assert_Integer NumberOfCustomers

Schlägt einer der Tests fehl, so wird eine "AssertionFailure" geworfen und die Aufrufkette für den Test in der LiveCode "Message Box" angezeigt - auf diese Weise kann die Stelle mit dem Fehler leichter aufgefunden werden.

Download und Installation

Die "TestLib" liegt als unverschlüsselter LiveCode-Stack bereit und kann von hier aus heruntergeladen werden:
Nach dem Herunterladen legen Sie die "TestLib" einfach in einem Verzeichnis Ihrer Wahl ab - eine explizite Installation ist nicht erforderlich.

Verwendung in Desktop-Anwendungen

Die "TestLib" wurde als LiveCode "Library Stack" implementiert und muss deshalb vor ihrer Verwendung zunächst einmalig mithilfe der Anweisung

start using stack "TestLib"

eingebunden werden. Zweckmäßigerweise wird diese Anweisung im Rahmen einer preOpenStack-Prozedur von einem MainStack ausgeführt.

Soll aus dem MainStack später eine eigenständige Anwendung werden, muss die "TestLib" außerdem Bestandteil der Liste der "Stack Files" zu diesem MainStack sein (am einfachsten geschieht dies mithilfe der "Standalone Application Settings" aus der LiveCode-Entwicklungsumgebung heraus).

Verwendung in mobilen Anwendungen

Die "TestLib" kann auch in mobilen Anwendungen eingesetzt werden. Allerdings muss sie dann - anders als für eigenständige Desktop-Anwendungen - in die Liste der "non-stack files" aufgenommen und mithilfe der Anweisung

start using stack (specialFolderPath("engine") & "/TestLib.livecode")

in den MainStack eingebunden werden. Die Liste der "non-stack files" findet sich ebenfalls auf der Seite "Copy Files" in den "Standalone Application Settings" der LiveCode-Entwicklungsumgebung.

Kommandoübersicht

Die "TestLib" enthält nur Kommandos, keine Funktionen.

Datentyp-Kontrollen

Manche der Tests prüfen ein gegebenes Argument auf einen passenden Datentyp. Dies sind (in alphabetischer Reihenfolge):

assert_Array <Candidate>


assert_Array verlangt, dass das mitgegebene Argument Candidate ein nicht-leeres LiveCode Array enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Boolean <Candidate>


assert_Boolean verlangt, dass das mitgegebene Argument Candidate ein gültigen booleschen Wert (also entweder true oder false) enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Color <Candidate>


assert_Color verlangt, dass das mitgegebene Argument Candidate ein gültigen Farbwert enthält. Dies kann ein Farbname ("green"), eine Spezifikation im HTML-Format ("#2255ab") oder eine Liste von RGB-Werten (255,255,255) sein. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Date <Candidate>


assert_Date verlangt, dass das mitgegebene Argument Candidate ein gültiges Datum enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Integer <Candidate>


assert_Integer verlangt, dass das mitgegebene Argument Candidate eine ganze Zahl enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Number <Candidate>


assert_Number verlangt, dass das mitgegebene Argument Candidate eine gültige Zahl enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Point <Candidate>


assert_Point verlangt, dass das mitgegebene Argument Candidate eine gültige Punktkoordinate (d.h., eine Liste bestehend aus zwei Zahlen) enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Rect <Candidate>


assert_Rect verlangt, dass das mitgegebene Argument Candidate einen Satz gültiger Rechteckkoordinaten (d.h., eine Liste bestehend aus vier Zahlen) enthält. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

Vergleichende Tests

Andere Tests vergleichen ein gegebenes Argument mit vorgegebenen Inhalten. Dies sind (in alphabetischer Reihenfolge):

assert_empty <Candidate>


assert_empty verlangt, dass das mitgegebene Argument Candidate leer ist (also den Wert empty enthält). Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_nonempty <Candidate>


assert_nonempty verlangt, dass das mitgegebene Argument Candidate nicht leer ist (also nicht den Wert empty enthält). Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_equals <expectedValue>, <actualValue>


assert_equals verlangt, dass das Argument actualValue (unabhängig von seinem Datentyp) denselben Inhalt wie der Erwartungswert expectedValue hat. Sind beide Argumente Zeichenketten, so wird bei deren Vergleich die aktuelle "CaseSensitive"-Einstellung berücksichtigt. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_differs <forbiddenValue>, <actualValue>


assert_differs verlangt, dass das Argument actualValue (unabhängig von seinem Datentyp) einen anderen Inhalt als der forbiddenValue hat. Sind beide Argumente Zeichenketten, so wird bei deren Vergleich die aktuelle "CaseSensitive"-Einstellung berücksichtigt. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_beginsWith <Prefix>, <actualValue>


assert_beginsWith verlangt, dass das Argument actualValue mit dem gegebenen Prefix beginnt - unter Berücksichtigung der aktuellen "CaseSensitive"-Einstellung. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_endsWith <Suffix>, <actualValue>


assert_endsWith verlangt, dass das Argument actualValue mit dem gegebenen Suffix endet - unter Berücksichtigung der aktuellen "CaseSensitive"-Einstellung. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

Kontrolle von Anweisungen

Eine weitere Sammlung von Tests befasst sich mit dem Erfolg oder Misserfolg von Anweisungen. Dies sind (in alphabetischer Reihenfolge):

assert_Success <Statement>


assert_Success verlangt, dass das mitgegebene Statement (repräsentiert durch eine Zeichenkette) ohne Werfen einer Ausnahme ausgeführt wird. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_Failure <SignalPrefix>, <Statement>


assert_Failure verlangt, dass das mitgegebene Statement (repräsentiert durch eine Zeichenkette) bei seiner Ausführung eine Ausnahme wirft, deren Text mit dem gegebenen SignalPrefix beginnt (der Vergleich wird unter Berücksichtigung der aktuellen "CaseSensitive"-Einstellung durchgeführt). Ist das SignalPrefix leer (d.h., enthält es den Wert empty), so erfüllt jede geworfene Ausnahme diese Bedingung. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

assert_DispatchSuccess <HandlerName> [, <TargetRef> [, <Argument> [, ...]]]


assert_DispatchSuccess verlangt, dass der an das Zielobjekt TargetRef geschickte Aufruf von HandlerName mit den angegebenen Argumenten ohne Werfen einer Ausnahme ausgeführt wird. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

Fehlt die Angabe von TargetRef, so wird der Aufruf an dasjenige Objekt geschickt, welches das laufende (Test-)Skript enthält.

Derzeit werden bis zu 16 Argumente unterstützt.

assert_DispatchFailure <SignalPrefix>, <HandlerName> [, <TargetRef> [, <Argument> [, ...]]]


assert_DispatchFailure verlangt, dass der an das Zielobjekt TargetRef geschickte Aufruf von HandlerName mit den angegebenen Argumenten bei seiner Ausführung eine Ausnahme wirft, deren Text mit dem gegebenen SignalPrefix beginnt (der Vergleich wird unter Berücksichtigung der aktuellen "CaseSensitive"-Einstellung durchgeführt). Ist das SignalPrefix leer (d.h., enthält es den Wert empty), so erfüllt jede geworfene Ausnahme diese Bedingung. Das Kommando verhält sich still, wenn diese Bedingung erfüllt ist, anderenfalls wirft es eine "AssertionFailure" und schreibt die Aufrufkette für den Test in die LiveCode "Message Box".

Fehlt die Angabe von TargetRef, so wird der Aufruf an dasjenige Objekt geschickt, welches das laufende (Test-)Skript enthält.

Derzeit werden bis zu 16 Argumente unterstützt.

System-Anforderungen

Die "TestLib" benötigt LiveCode 6.x oder neuer und funktioniert unabhängig vom jeweiligen Betriebssystem sowohl auf stationären wie auch auf mobilen Plattformen.

Abhängigkeiten

Die "TestLib" verwendet intern die "BasicLib" - beim Einsatz der "TestLib" muss diese also ebenfalls vorhanden sein.

Automatisierte Tests

Für die "TestLib" steht auch ein separater Stack mit automatisierten Tests dieser Bibliothek bereit:
Beim Öffnen dieses Stack wird zugleich auch das Kommando performTests ausgeführt, welches für die eigentlichen Tests zuständig ist. Am Ende sollte die "Message Box" der LiveCode-Entwicklungsumgebung erscheinen und die Meldung

all tests passed

angezeigt werden - anderenfalls sollte dort stattdessen eine Fehlermeldung mit Hinweisen zum fehlgeschlagenen Test zu finden sein.

Bekannte Fehler

Derzeit sind keine Fehler der "TestLib" bekannt.

Lizenz-Hinweis

Die "TestLib" und die zugehörigen Tests unterliegen der "Creative Commons Namensnennung 4.0 Unported Lizenz", was im Wesentlichen bedeutet, dass Sie beides (selbst in kommerziellem Rahmen) sowohl verwenden als auch verändern dürfen, sofern Sie Ihre Änderungen als solche kenntlich machen und an geeigneter Stelle auf mich als den ursprünglichen Autor hinweisen.

                       
Viel Spaß mit LiveCode und meinen Bibliotheken! Creative Commons Lizenzvertrag

Literaturhinweise

[1]
(RunRev Ltd.)
LiveCode | Create apps for multiple platforms. Quickly. Easily. Free
LiveCode ist eine (dem legendären HyperCard von Apple) nachempfundene Entwicklungsumgebung sowohl für stationäre (Windows, Linux, MacOS X) als auch für mobile (IOS, Android) Anwendungen. Ein visueller Editor ermöglicht den schnellen Entwurf von Bedienoberflächen, die der englischen Sprache nachempfundene Programmiersprache erlaubt auch Nicht-Programmierprofis die Entwicklung professioneller Anwendungen und das Konzept der "Modifikation am laufenden Programm" vereinfacht Test und Fehlerbehebung.