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
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:
perl-Test-Deep; openSUSE: perl-Test-Deep)
Test::Exception (Debian-Paketname: libtest-exception-perl; Fedora Core:
perl-Test-Exception; openSUSE: perl-Test-Exception)
Test::Output (Debian-Paketname: libtest-output-perl; Fedora Core:
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.
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 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
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
(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.