X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=inline;f=doc%2Fhtml%2Fch04s05.html;h=5c47f74c61d1eaab9197e80b10bff619a205046e;hb=2c33e93fb5caf10f96cfa462781830f28efa285c;hp=6260a276c1ad1eb51a713e10bd6c5588a30be14b;hpb=eb496376260c7360d5bc53d865c38d47a9685fda;p=kivitendo-erp.git diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html index 6260a276c..5c47f74c6 100644 --- a/doc/html/ch04s05.html +++ b/doc/html/ch04s05.html @@ -1,55 +1,115 @@
-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; +4.5. Die kivitendo-Test-Suite \ No newline at end of file +Support::TestSetup::login();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
)+
Sys::CPU
(Debian-Panetname: +libsys-cpu-perl
; Fedora und openSUSE: nicht + vorhanden)+
Thread::Pool::Simple
(Debian-Panetname: +libthread-pool-simple-perl
; Fedora und + openSUSE: nicht vorhanden)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.Der so angegebene Benutzer muss nicht zwingend über + Super-User-Rechte verfügen. Allerdings gibt es einige + Datenbank-Upgrades, die genau diese Rechte benötigen. Für den Fall + kann man in diesem Konfigurationsabschnitt einen weiteren + Benutzeraccount angeben, der dann über Super-User-Rechte verfügt, und + mit dem die betroffenen Upgrades durchgeführt werden. In der + Beispiel-Konfigurationsdatei finden Sie die benötigten + Parameter.
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.tDie 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()
undexec()
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ültigkeitWeitere 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 sindTest, ob alle Webseiten-Templates in +
templates/webpages
mit vom Perl-Modul +Template
compiliert werden könnenEs 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 Abschnitttesting.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.
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.