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:
perl-Test-Deep; openSUSE:
perl-Test-Deep)
Test::Exception (Debian-Paketname:
libtest-exception-perl; Fedora:
perl-Test-Exception; openSUSE:
perl-Test-Exception)
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:
perl-libwww-perl; openSUSE:
perl-libwww-perl)
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 gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder,
man lässt alle Tests auf einmal ausführen, oder man führt gezielt
einzelne Scripte aus. Für beide Fälle gibt es das Helferscript
t/test.pl.
Will man die komplette Test-Suite ausführen, so muss man einfach
nur t/test.pl ohne weitere Parameter aus dem
kivitendo-Basisverzeichnis heraus ausführen.
Um einzelne Test-Scripte auszuführen, übergibt man deren Namen
an t/test.pl. Beispielsweise:
t/test.pl t/form/format_amount.t t/background_job/known_jobs.t
Die Test-Suite umfasst Tests sowohl für Funktionen als auch für Programmierstil. Einige besonders zu erwähnende, weil auch während der Entwicklung nützliche Tests sind:
t/001compile.t -- compiliert alle
Quelldateien und bricht bei Fehlern sofort ab
t/002goodperl.t -- überprüft alle
Perl-Dateien auf Anwesenheit von 'use
strict'-Anweisungen
t/003safesys.t -- überprüft Aufrufe von
system() und exec() auf
Gültigkeit
t/005no_tabs.t -- überprüft, ob Dateien
Tab-Zeichen enthalten
t/006spelling.t -- sucht nach häufigen
Rechtschreibfehlern
t/011pod.t -- überprüft die Syntax von
Dokumentation im POD-Format auf Gültigkeit
Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.
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 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 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.
Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:
use Test::More tests => 0; use lib 't'; use Support::TestSetup; Support::TestSetup::login();
Wird eine vollständig initialisierte kivitendo-Umgebung
benötigt (Stichwort: alle globalen Variablen wie
$::auth, $::form oder
$::lxdebug), so muss in der Konfigurationsdatei
config/kivitendo.conf im Abschnitt
testing.login ein gültiger Login-Name eingetragen
sein. Dieser wird für die Datenbankverbindung benötigt.
Wir keine vollständig initialisierte Umgebung benötigt, so
kann die letzte Zeile Support::TestSetup::login();
weggelassen werden, was die Ausführungszeit des Scripts leicht
verringert.