4.5. Die kivitendo-Test-Suite

4.5.1. Einführung

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.

4.5.2. Voraussetzungen

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.

4.5.3. Existierende Tests ausführen

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.sh.

Will man die komplette Test-Suite ausführen, so muss man einfach nur t/test.sh ohne weitere Parameter aus dem kivitendo-Basisverzeichnis heraus ausführen.

Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an t/test.sh. Beispielsweise:

t/test.sh t/form/format_amount.t t/background_job/known_jobs.t

4.5.4. Bedeutung der verschiedenen Test-Scripte

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.

4.5.5. Neue Test-Scripte erstellen

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.

4.5.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen testen

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

4.5.5.2. Konvention für Verzeichnis- und Dateinamen

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.

4.5.5.3. Minimales Skelett für eigene Scripte

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.