X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fhtml%2Fch04s05.html;h=0e0ee206342f9bb70a8553f3b7f219462d734512;hb=c3fa430edf27cefc8d45597e8784d0e847a72ff4;hp=87fee77026c9061b7c361a21a20f0ff610b94920;hpb=8a40e3dd0f638557b8c666fe708ccbc1ac709c4e;p=kivitendo-erp.git diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html index 87fee7702..0e0ee2063 100644 --- a/doc/html/ch04s05.html +++ b/doc/html/ch04s05.html @@ -1,13 +1,27 @@
-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:
- perl-Test-Deep
; openSuSE: perl-Test-Deep
)
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.
+ LWP::Simple
aus dem Paket libwww-perl
(Debian-Panetname:
+ libwww-perl
; Fedora Core: perl-libwww-perl
; openSUSE:
+ perl-libwww-perl
)
+ URI::Find
(Debian-Panetname: liburi-find-perl
; Fedora Core:
+ 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.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
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
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.