X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fhtml%2Fch04s05.html;h=cc2d124b76c52e119ed0033cd7be943dea8ffffb;hb=c62a6cabffc11bdb2d3fda2025fef2f3d07c5ba9;hp=18da9b1424a21b3c27edabb424f0d800c772ee46;hpb=d2ab33ea45cee261d98267e4c336e5cd7be8521e;p=kivitendo-erp.git diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html index 18da9b142..cc2d124b7 100644 --- a/doc/html/ch04s05.html +++ b/doc/html/ch04s05.html @@ -1,106 +1,100 @@ - 4.5. Die kivitendo-Test-Suite

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

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

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

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

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

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;
+   4.5. Translations and languages

4.5. Translations and languages

4.5.1. Introduction

[Anmerkung]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.

4.5.2. Character set

All files included in a language pack must use UTF-8 as their + encoding.

4.5.3. File structure

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 missing

A 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 a num2text sub. If + an init 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
+&=&amp;
+<=&lt;
+>=&gt;
+\n=<br>

Note the importance of the order in this example. + Substituting < and > befor & would lead to $gt; become + &amp;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
+filenames

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

\ No newline at end of file +$self->{more_texts} = { + + 'Ship via' => 'Terms of delivery', + 'Shipping Point' => 'Delivery time', +} +

+

\ No newline at end of file