X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=inline;f=doc%2Fhtml%2Fch04s05.html;h=59bda4a29f36659e2f9d3e15f30763e474bb3f87;hb=535330c547f770e2b5fa27940a50f3ad04a1ba28;hp=87fee77026c9061b7c361a21a20f0ff610b94920;hpb=16df30aaca2c8d4173f1ea76be206ef5a23e69c9;p=kivitendo-erp.git diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html index 87fee7702..59bda4a29 100644 --- a/doc/html/ch04s05.html +++ b/doc/html/ch04s05.html @@ -1,41 +1,100 @@
-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
)
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
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; +4.5. Translations and languages \ No newline at end of file +$self->{more_texts} = { + + 'Ship via' => 'Terms of delivery', + 'Shipping Point' => 'Delivery time', +} +
Anmerkung Dieser Abschnitt ist in Englisch geschrieben, um + internationalen Ãbersetzern die Arbeit zu erleichtern.
This section describes how localization packages in kivitendo + are built. Currently the only language fully supported is German, and + since most of the internal messages are held in English the English + version is usable too.
The structure of locales in kivitendo is:
kivitendo/locale/<langcode>/where <langcode> stands for an abbreviation of the + language package. The builtin packages use two letter ISO 639-1 codes, + but the actual name is not relevant for the program and can easily be + extended to IETF language + tags (i.e. "en_GB"). In fact the original language packages + from SQL Ledger are named in this way.
In such a language directory the following files are + recognized:
- LANGUAGE
This file is mandatory.
The
LANGUAGE
file contains the self + descripted name of the language. It should contain a native + representation first, and in parenthesis an english translation + after that. Example:Deutsch (German)- all
This file is mandatory.
The central translation file. It is essentially an inline + Perl script autogenerated by locales.pl. To + generate it, generate the directory and the two files mentioned + above, and execute the following command:
scripts/locales.pl <langcode>Otherwise you can simply copy one of the other languages. + You will be told how many are missing like this:
$ scripts/locales.pl en +English - 0.6% - 2015/2028 missingA file named "
missing
" will be + generated and can be edited. You can also edit the + "all
" file directly. Edit everything you + like to fit the target language and execute + locales.pl again. See how the missing words + get fewer.- Num2text
Legacy code from SQL Ledger. It provides a means for + numbers to be converted into natural language, like +
1523 => one thousand five hundred twenty + three
. If you want to provide it, it must be inlinable + Perl code which provides anum2text
sub. If + aninit
sub exists it will be executed + first.Only used in the check and receipt printing module.
- special_chars
kivitendo comes with a lot of interfaces to different + formats, some of which are rather picky with their accepted + charset. The
special_chars
file contains a + listing of chars not suited for different file format and + provides substitutions. It is written in "Simple Ini" style, + containing a block for every file format.First entry should be the order of substitution for + entries as a whitespace separated list. All entries are + interpolated, so
\n
,\x20
+ and\\
all work.After that every entry is a special char that should be + translated when writing text into such a file.
Example:
[Template/XML] +order=& < > \n +&=& +<=< +>=> +\n=<br>Note the importance of the order in this example. + Substituting < and > befor & would lead to $gt; become + &gt;
For a list of valid formats, see the German +
special_chars
entry. As of this writing the + following are recognized:HTML +URL@HTML +Template/HTML +Template/XML +Template/LaTeX +Template/OpenDocument +filenamesThe last of which is very machine dependent. Remember that + a lot of characters are forbidden by some filesystems, for + example MS Windows doesn't like ':' in its files where Linux + doesn't mind that. If you want the files created with your + language pack to be portable, find all chars that could cause + trouble.
- missing
This file is not a part of the language package + itself.
This is a file generated by + scripts/locales.pl while processing your + locales. It's only to have the missing entries singled out and + does not belong to a language package.
- lost
This file is not a part of the language package + itself.
Another file generated by + scripts/locales.pl. If for any reason a + translation does not appear anymore and can be deleted, it gets + moved here. The last 50 or so entries deleted are saved here in + case you made a typo, so that you don't have to translate + everything again. If a tranlsation is missing, the lost file is + checked first. If you maintain a language package, you might + want to keep this safe somewhere.
- more/all
This subdir and file is not a part of the language package + itself.
If the directory more exists and contains a file called + all it will be parsed in addition to the mandatory all (see + above). The file is useful if you want to change some + translations for the current installation without conflicting + further upgrades. The file is not autogenerated and has the same + format as the all, but needs another key (more_texts). See the + german translation for an example or copy the following code: +
+#!/usr/bin/perl +# -*- coding: utf-8; -*- +# vim: fenc=utf-8 -use lib 't'; +use utf8; -use Support::TestSetup; +# These are additional texts for custom translations. +# The format is the same as for the normal file all, only +# with another key (more_texts instead of texts). +# The file has the form of 'english text' => 'foreign text', -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.
+