kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul Test::More.
Die grundlegenden Fakten sind:
Alle Tests liegen im Unterverzeichnis t/.
Ein Script (bzw. ein Test) in f/ enthält einen oder mehrere Testfälle.
Alle Dateinamen von Tests enden auf .t. Es sind selbstständig ausführbare Perl-Scripte.
Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in f/, deren
+
kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul Test::More.
Die grundlegenden Fakten sind:
Alle Tests liegen im Unterverzeichnis t/.
Ein Script (bzw. ein Test) in t/ enthält einen oder mehrere Testfälle.
Alle Dateinamen von Tests enden auf .t. Es sind selbstständig ausführbare Perl-Scripte.
Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in t/, deren
Dateiname auf .t endet.
Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:
- Test::Deep (Debian-Paketname: libtest-deep-perl; Fedora Core:
+ Test::Deep (Debian-Paketname: libtest-deep-perl; Fedora:
perl-Test-Deep; openSUSE: perl-Test-Deep)
- Test::Exception (Debian-Paketname: libtest-exception-perl; Fedora Core:
+ Test::Exception (Debian-Paketname: libtest-exception-perl; Fedora:
perl-Test-Exception; openSUSE: perl-Test-Exception)
- Test::Output (Debian-Paketname: libtest-output-perl; Fedora Core:
+ Test::Output (Debian-Paketname: libtest-output-perl; Fedora:
perl-Test-Output; openSUSE: perl-Test-Output)
Test::Harness 3.0.0 oder höher. Dieses Modul ist ab Perl 5.10.1 Bestandteil der
Perl-Distribution und kann für frühere Versionen aus dem CPAN bezogen
werden.
LWP::Simple aus dem Paket libwww-perl (Debian-Panetname:
- libwww-perl; Fedora Core: perl-libwww-perl; openSUSE:
+ libwww-perl; Fedora: perl-libwww-perl; openSUSE:
perl-libwww-perl)
- URI::Find (Debian-Panetname: liburi-find-perl; Fedora Core:
+ URI::Find (Debian-Panetname: liburi-find-perl; Fedora:
perl-URI-Find; openSUSE: perl-URI-Find)
Weitere Voraussetzung ist, dass die Testsuite ihre eigene Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
müssen in der Konfigurationsdatei im Abschnit testing/database Datenbankverbindungsparameter angegeben
werden. Der hier angegebene Benutzer muss weiterhin das Recht haben, Datenbanken anzulegen und zu löschen.
Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich mit einem Test-Script abgesichert wird. Auch bestehende Funktion darf und soll ausdrücklich nachträglich mit Test-Scripten abgesichert werden.
Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:
Ãberprüfung auf fehlende symbolische Links
Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)
Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)
Ãberprüfung auf Leerzeichen am Ende von Zeilen
Test, ob alle zu übersetzenden Strings in locale/de/all vorhanden sind
Test, ob alle Webseiten-Templates in templates/webpages mit vom Perl-Modul Template compiliert werden können
Ideen, die abgesehen von Funktionen noch nicht umgesetzt wurden:
Ãberprüfung auf fehlende symbolische Links
Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)
Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)
Ãberprüfung auf Leerzeichen am Ende von Zeilen
Test, ob alle zu übersetzenden Strings in locale/de/all vorhanden sind
Test, ob alle Webseiten-Templates in templates/webpages mit vom Perl-Modul Template compiliert werden können
Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten und ihnen soweit es geht folgen:
Die Dateiendung muss .t lauten.
Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise
- bad_function_params.t).
Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen
+ bad_function_params.t).
Unterverzeichnisse sollten grob nach dem Themenbereich benannt sein, mit dem sich die Scripte darin befassen
(beispielsweise background_jobs für Tests rund um Hintergrund-Jobs).
Test-Scripte sollten einen überschaubaren Bereich von Funktionalität testen, der logisch zusammenhängend ist (z.B. nur Tests für eine einzelne Funktion in einem Modul). Lieber mehrere Test-Scripte schreiben.