Revision d1564e8a
Von Moritz Bunkus vor mehr als 12 Jahren hinzugefügt
| doc/dokumentation.xml | ||
|---|---|---|
|
</sect2>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="devel.testsuite">
|
||
|
<title>Die kivitendo-Test-Suite</title>
|
||
|
|
||
|
<sect2 id="devel.testsuite.intro">
|
||
|
<title>Einführung</title>
|
||
|
|
||
|
<para>kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul <literal>Test::More</literal>.</para>
|
||
|
|
||
|
<para>Die grundlegenden Fakten sind:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem><para>Alle Tests liegen im Unterverzeichnis <filename>t/</filename>.</para></listitem>
|
||
|
|
||
|
<listitem><para>Ein Script (bzw. ein Test) in <filename>f/</filename> enthält einen oder mehrere Testfälle.</para></listitem>
|
||
|
|
||
|
<listitem><para>Alle Dateinamen von Tests enden auf <literal>.t</literal>. Es sind selbstständig ausführbare Perl-Scripte.</para></listitem>
|
||
|
|
||
|
<listitem><para>Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in <filename>f/</filename>, deren
|
||
|
Dateiname auf <literal>.t</literal> endet.</para></listitem>
|
||
|
</itemizedlist>
|
||
|
</sect2>
|
||
|
|
||
|
<sect2 id="devel.testsuite.prerequisites">
|
||
|
<title>Voraussetzungen</title>
|
||
|
|
||
|
<para>Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem><para><literal>Test::Deep</literal> (Debian-Paketname: <literal>libtest-deep-perl</literal>; Fedora Core:
|
||
|
<literal>perl-Test-Deep</literal>; openSuSE: <literal>perl-Test-Deep</literal>)</para></listitem>
|
||
|
</itemizedlist>
|
||
|
</sect2>
|
||
|
|
||
|
<sect2 id="devel.testsuite.execution">
|
||
|
<title>
|
||
|
Existierende Tests ausführen
|
||
|
</title>
|
||
|
|
||
|
<para>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 <filename>t/test.sh</filename>.</para>
|
||
|
|
||
|
<para>Will man die komplette Test-Suite ausführen, so muss man einfach nur <filename>t/test.sh</filename> ohne weitere Parameter aus
|
||
|
dem kivitendo-Basisverzeichnis heraus ausführen.</para>
|
||
|
|
||
|
<para>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <filename>t/test.sh</filename>. Beispielsweise:</para>
|
||
|
|
||
|
<programlisting>t/test.sh t/form/format_amount.t t/background_job/known_jobs.t</programlisting>
|
||
|
</sect2>
|
||
|
|
||
|
|
||
|
<sect2 id="devel.testsuite.meaning_of_scripts">
|
||
|
<title>
|
||
|
Bedeutung der verschiedenen Test-Scripte
|
||
|
</title>
|
||
|
|
||
|
<para>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:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem><para><filename>t/001compile.t</filename> -- compiliert alle Quelldateien und bricht bei Fehlern sofort ab</para></listitem>
|
||
|
<listitem><para><filename>t/002goodperl.t</filename> -- überprüft alle Perl-Dateien auf Anwesenheit von '<literal>use strict</literal>'-Anweisungen</para></listitem>
|
||
|
<listitem><para><filename>t/003safesys.t</filename> -- überprüft Aufrufe von <function>system()</function> und <function>exec()</function> auf Gültigkeit</para></listitem>
|
||
|
<listitem><para><filename>t/005no_tabs.t</filename> -- überprüft, ob Dateien Tab-Zeichen enthalten</para></listitem>
|
||
|
<listitem><para><filename>t/006spelling.t</filename> -- sucht nach häufigen Rechtschreibfehlern</para></listitem>
|
||
|
<listitem><para><filename>t/011pod.t</filename> -- überprüft die Syntax von Dokumentation im POD-Format auf Gültigkeit</para></listitem>
|
||
|
</itemizedlist>
|
||
|
|
||
|
<para>Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.</para>
|
||
|
</sect2>
|
||
|
|
||
|
<sect2 id="devel.testsuite.create_new">
|
||
|
<title>
|
||
|
Neue Test-Scripte erstellen
|
||
|
</title>
|
||
|
|
||
|
<para>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.</para>
|
||
|
|
||
|
<sect3 id="devel.testsuite.ideas_for_non_function_tests">
|
||
|
<title>
|
||
|
Ideen für neue Test-Scripte, die keine konkreten Funktionen testen
|
||
|
</title>
|
||
|
|
||
|
<para> Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem><para>Überprüfung auf fehlende symbolische Links</para></listitem>
|
||
|
<listitem><para>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)</para></listitem>
|
||
|
<listitem><para>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</para></listitem>
|
||
|
<listitem><para>Überprüfung auf Leerzeichen am Ende von Zeilen</para></listitem>
|
||
|
<listitem><para>Test, ob alle zu übersetzenden Strings in <filename>locale/de/all</filename> vorhanden sind</para></listitem>
|
||
|
<listitem><para>Test, ob alle Webseiten-Templates in <filename>templates/webpages</filename> mit vom Perl-Modul <literal>Template</literal> compiliert werden können</para></listitem>
|
||
|
</itemizedlist>
|
||
|
</sect3>
|
||
|
|
||
|
<sect3 id="devel.testsuite.directory_and_test_names">
|
||
|
<title>
|
||
|
Konvention für Verzeichnis- und Dateinamen
|
||
|
</title>
|
||
|
|
||
|
<para>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:</para>
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem><para>Die Dateiendung muss <filename>.t</filename> lauten.</para></listitem>
|
||
|
|
||
|
<listitem><para>Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise
|
||
|
<filename>bad_function_params.t</filename>).</para></listitem>
|
||
|
|
||
|
<listitem><para>Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen
|
||
|
(beispielsweise <filename>background_jobs</filename> für Tests rund um Hintergrund-Jobs).</para></listitem>
|
||
|
|
||
|
<listitem><para>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.</para></listitem>
|
||
|
</itemizedlist>
|
||
|
</sect3>
|
||
|
|
||
|
<sect3 id="devel.testsuite.minimal_example">
|
||
|
<title>
|
||
|
Minimales Skelett für eigene Scripte
|
||
|
</title>
|
||
|
|
||
|
<para>Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:</para>
|
||
|
|
||
|
<programlisting>use Test::More tests => 0;
|
||
|
|
||
|
use lib 't';
|
||
|
|
||
|
use Support::TestSetup;
|
||
|
|
||
|
Support::TestSetup::login();</programlisting>
|
||
|
|
||
|
<para>Wird eine vollständig initialisierte kivitendo-Umgebung benötigt (Stichwort: alle globalen Variablen wie
|
||
|
<varname>$::auth</varname>, <varname>$::form</varname> oder <varname>$::lxdebug</varname>), so muss in der Konfigurationsdatei
|
||
|
<filename>config/kivitendo.conf</filename> im Abschnitt <literal>testing.login</literal> ein gültiger Login-Name eingetragen
|
||
|
sein. Dieser wird für die Datenbankverbindung benötigt.</para>
|
||
|
|
||
|
<para>Wir keine vollständig initialisierte Umgebung benötigt, so kann die letzte Zeile <code>Support::TestSetup::login();</code>
|
||
|
weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.</para>
|
||
|
</sect3>
|
||
|
</sect2>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="devel.style-guide">
|
||
|
<title>Stil-Richtlinien</title>
|
||
|
|
||
| doc/html/ch04s04.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.4. Translations and languages</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s03.html" title="4.3. SQL-Upgradedateien"><link rel="next" href="ch04s05.html" title="4.5. Stil-Richtlinien"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.4. Translations and languages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.4. Translations and languages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="translations-languages"></a>4.4. Translations and languages</h2></div></div></div><div class="sect2" title="4.4.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.introduction"></a>4.4.1. Introduction</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="../../../../system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Dieser Abschnitt ist in Englisch geschrieben, um
|
||
|
<title>4.4. Translations and languages</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s03.html" title="4.3. SQL-Upgradedateien"><link rel="next" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.4. Translations and languages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.4. Translations and languages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="translations-languages"></a>4.4. Translations and languages</h2></div></div></div><div class="sect2" title="4.4.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.introduction"></a>4.4.1. Introduction</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="../../../../system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Dieser Abschnitt ist in Englisch geschrieben, um
|
||
|
internationalen Übersetzern die Arbeit zu erleichtern.</p></td></tr></table></div><p>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
|
||
| ... | ... | |
|
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.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. SQL-Upgradedateien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.5. Stil-Richtlinien</td></tr></table></div></body></html>
|
||
|
want to keep this safe somewhere.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. SQL-Upgradedateien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.5. Die kivitendo-Test-Suite</td></tr></table></div></body></html>
|
||
| doc/html/ch04s05.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.5. Stil-Richtlinien</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s04.html" title="4.4. Translations and languages"><link rel="next" href="ch04s06.html" title="4.6. Dokumentation erstellen"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.5. Stil-Richtlinien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.5. Stil-Richtlinien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.style-guide"></a>4.5. Stil-Richtlinien</h2></div></div></div><p>Die folgenden Regeln haben das Ziel, den Code möglichst gut les-
|
||
|
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich
|
||
|
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden
|
||
|
wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das
|
||
|
Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher
|
||
|
überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere
|
||
|
nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen
|
||
|
verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {
|
||
|
if ($flag) {
|
||
|
# do something with $row
|
||
|
}
|
||
|
<title>4.5. Die kivitendo-Test-Suite</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s04.html" title="4.4. Translations and languages"><link rel="next" href="ch04s06.html" title="4.6. Stil-Richtlinien"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.5. Die kivitendo-Test-Suite</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.5. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.5. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.5.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.5.1. Einführung</h3></div></div></div><p>kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul <code class="literal">Test::More</code>.</p><p>Die grundlegenden Fakten sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Alle Tests liegen im Unterverzeichnis <code class="filename">t/</code>.</p></li><li class="listitem"><p>Ein Script (bzw. ein Test) in <code class="filename">f/</code> enthält einen oder mehrere Testfälle.</p></li><li class="listitem"><p>Alle Dateinamen von Tests enden auf <code class="literal">.t</code>. Es sind selbstständig ausführbare Perl-Scripte.</p></li><li class="listitem"><p>Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in <code class="filename">f/</code>, deren
|
||
|
Dateiname auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.5.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.5.2. Voraussetzungen</h3></div></div></div><p>Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="literal">Test::Deep</code> (Debian-Paketname: <code class="literal">libtest-deep-perl</code>; Fedora Core:
|
||
|
<code class="literal">perl-Test-Deep</code>; openSuSE: <code class="literal">perl-Test-Deep</code>)</p></li></ul></div></div><div class="sect2" title="4.5.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.5.3.
|
||
|
Existierende Tests ausführen
|
||
|
</h3></div></div></div><p>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 <code class="filename">t/test.sh</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach nur <code class="filename">t/test.sh</code> ohne weitere Parameter aus
|
||
|
dem kivitendo-Basisverzeichnis heraus ausführen.</p><p>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an <code class="filename">t/test.sh</code>. Beispielsweise:</p><pre class="programlisting">t/test.sh t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.5.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.5.4.
|
||
|
Bedeutung der verschiedenen Test-Scripte
|
||
|
</h3></div></div></div><p>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:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="filename">t/001compile.t</code> -- compiliert alle Quelldateien und bricht bei Fehlern sofort ab</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/002goodperl.t</code> -- überprüft alle Perl-Dateien auf Anwesenheit von '<code class="literal">use strict</code>'-Anweisungen</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/003safesys.t</code> -- überprüft Aufrufe von <code class="function">system()</code> und <code class="function">exec()</code> auf Gültigkeit</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/005no_tabs.t</code> -- überprüft, ob Dateien Tab-Zeichen enthalten</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/006spelling.t</code> -- sucht nach häufigen Rechtschreibfehlern</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/011pod.t</code> -- überprüft die Syntax von Dokumentation im POD-Format auf Gültigkeit</p></li></ul></div><p>Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.</p></div><div class="sect2" title="4.5.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.5.5.
|
||
|
Neue Test-Scripte erstellen
|
||
|
</h3></div></div></div><p>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.</p><div class="sect3" title="4.5.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen testen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.ideas_for_non_function_tests"></a>4.5.5.1.
|
||
|
Ideen für neue Test-Scripte, die keine konkreten Funktionen testen
|
||
|
</h4></div></div></div><p> Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Überprüfung auf fehlende symbolische Links</p></li><li class="listitem"><p>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)</p></li><li class="listitem"><p>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</p></li><li class="listitem"><p>Überprüfung auf Leerzeichen am Ende von Zeilen</p></li><li class="listitem"><p>Test, ob alle zu übersetzenden Strings in <code class="filename">locale/de/all</code> vorhanden sind</p></li><li class="listitem"><p>Test, ob alle Webseiten-Templates in <code class="filename">templates/webpages</code> mit vom Perl-Modul <code class="literal">Template</code> compiliert werden können</p></li></ul></div></div><div class="sect3" title="4.5.5.2. Konvention für Verzeichnis- und Dateinamen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.directory_and_test_names"></a>4.5.5.2.
|
||
|
Konvention für Verzeichnis- und Dateinamen
|
||
|
</h4></div></div></div><p>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:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Die Dateiendung muss <code class="filename">.t</code> lauten.</p></li><li class="listitem"><p>Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise
|
||
|
<code class="filename">bad_function_params.t</code>).</p></li><li class="listitem"><p>Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen
|
||
|
(beispielsweise <code class="filename">background_jobs</code> für Tests rund um Hintergrund-Jobs).</p></li><li class="listitem"><p>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.</p></li></ul></div></div><div class="sect3" title="4.5.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.5.5.3.
|
||
|
Minimales Skelett für eigene Scripte
|
||
|
</h4></div></div></div><p>Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:</p><pre class="programlisting">use Test::More tests => 0;
|
||
|
|
||
|
if ($use_modules) {
|
||
|
$row->{modules} = MODULE->retrieve(
|
||
|
id => $row->{id},
|
||
|
date => $use_now ? localtime() : $row->{time},
|
||
|
);
|
||
|
}
|
||
|
use lib 't';
|
||
|
|
||
|
$report->add($row);
|
||
|
}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen
|
||
|
Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {
|
||
|
...
|
||
|
}</pre><p>oder</p><pre class="programlisting">if ($form->{item_rows} > 0) {
|
||
|
...
|
||
|
}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie
|
||
|
der Befehl / die öffnende schließende Klammer, die den Block
|
||
|
gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen
|
||
|
Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>",
|
||
|
"<code class="function">elsif</code>", "<code class="function">while</code>" befinden
|
||
|
sich auf der gleichen Zeile wie schließende geschweifte Klammern.
|
||
|
Beispiele:</p><pre class="programlisting">if ($form->{sum} > 1000) {
|
||
|
...
|
||
|
} elsif ($form->{sum} > 0) {
|
||
|
...
|
||
|
} else {
|
||
|
...
|
||
|
}
|
||
|
use Support::TestSetup;
|
||
|
|
||
|
do {
|
||
|
...
|
||
|
} until ($a > 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern
|
||
|
versehen werden. Davon nicht betroffen sind interne Perl-Funktionen,
|
||
|
und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug->message("Could not find file.");
|
||
|
%options = map { $_ => 1 } grep { !/^#/ } @config_file;</pre></li><li class="listitem"><p>Verschiedene Klammern, Ihre Ausdrücke und Leerzeichen:</p><p>Generell gilt: Hashkeys und Arrayindices sollten nicht durch
|
||
|
Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig,
|
||
|
Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form->{debug} == 1) && ($form->{sum} - 100 < 0)) {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
$array[$i + 1] = 4;
|
||
|
$form->{sum} += $form->{"row_$i"};
|
||
|
$form->{ $form->{index} } += 1;
|
||
|
|
||
|
map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;</pre></li><li class="listitem"><p>Mehrzeilige Befehle</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Werden die Parameter eines Funktionsaufrufes auf mehrere
|
||
|
Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt
|
||
|
werden, in der die ersten Funktionsparameter in der ersten Zeile
|
||
|
stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh->prepare("SELECT * FROM some_table WHERE col = ?",
|
||
|
$form->{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Oprator "?:", der am
|
||
|
besten in einer übersichtlichen Tabellenstruktur organisiert
|
||
|
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form->{"row_$i"} ? $i
|
||
|
: $form->{oldcount} ? $form->{oldcount} + 1
|
||
|
: $form->{rowcount} - $form->{rowbase};</pre></li></ol></div></li><li class="listitem"><p>Kommentare</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Kommentare, die alleine in einer Zeile stehen, sollten
|
||
|
soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich
|
||
|
formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte
|
||
|
auf Englisch zu verfassen. So wie ich keine Lust habe,
|
||
|
französischen Quelltext zu lesen, sollte auch der kivitendo
|
||
|
Quelltext für nicht-Deutschsprachige lesbar sein.
|
||
|
Beispiel:</p><pre class="programlisting">my $found = 0;
|
||
|
while (1) {
|
||
|
last if $found;
|
||
|
|
||
|
# complicated check
|
||
|
$found = 1 if //
|
||
|
}
|
||
|
|
||
|
$i = 0 # initialize $i
|
||
|
$n = $i; # save $i
|
||
|
$i *= $const; # do something crazy
|
||
|
$i = $n; # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die
|
||
|
Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form->{sum} = 0;
|
||
|
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
||
|
$some_hash{42} = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen
|
||
|
unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber
|
||
|
wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in
|
||
|
grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion
|
||
|
<code class="function">print_options</code> aus
|
||
|
<code class="filename">bin/mozilla/io.pl</code> angeführt.</p></li><li class="listitem"><p>Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind
|
||
|
unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs
|
||
|
verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur
|
||
|
Entfernung von trailing whitespace. Emacs kennt das Kommande
|
||
|
<span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche
|
||
|
manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au
|
||
|
BufWritePre * :%s/\s\+$//e</code> wird das an Speichern
|
||
|
gebunden.</p></li><li class="listitem"><p>Es wird kein <span class="command"><strong>perltidy</strong></span> verwendet.</p><p>In der Vergangenheit wurde versucht,
|
||
|
<span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen
|
||
|
Stil zu erlangen. Es hat sich aber gezeigt, dass
|
||
|
<span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was
|
||
|
Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für
|
||
|
den Interessierten sind hier die
|
||
|
<span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen
|
||
|
Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm
|
||
|
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79
|
||
|
-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p>
|
||
|
<code class="varname">STDERR</code> ist tabu. Unkonditionale
|
||
|
Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code>
|
||
|
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen
|
||
|
Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode
|
||
|
"<code class="function">message</code>" nimmt als ersten Paramter außerdem
|
||
|
eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer
|
||
|
angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden
|
||
|
und werden in den meisten Fällen auch vom Repository
|
||
|
zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p>
|
||
|
<code class="varname">$form</code>, <code class="varname">$auth</code>,
|
||
|
<code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und
|
||
|
<code class="varname">%myconfig</code> werden derzeit aus dem main package
|
||
|
importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen
|
||
|
Konstrukte sollten lexikalisch lokal gehalten werden.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.4. Translations and languages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.6. Dokumentation erstellen</td></tr></table></div></body></html>
|
||
|
Support::TestSetup::login();</pre><p>Wird eine vollständig initialisierte kivitendo-Umgebung benötigt (Stichwort: alle globalen Variablen wie
|
||
|
<code class="varname">$::auth</code>, <code class="varname">$::form</code> oder <code class="varname">$::lxdebug</code>), so muss in der Konfigurationsdatei
|
||
|
<code class="filename">config/kivitendo.conf</code> im Abschnitt <code class="literal">testing.login</code> ein gültiger Login-Name eingetragen
|
||
|
sein. Dieser wird für die Datenbankverbindung benötigt.</p><p>Wir keine vollständig initialisierte Umgebung benötigt, so kann die letzte Zeile <code class="code">Support::TestSetup::login();</code>
|
||
|
weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.4. Translations and languages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.6. Stil-Richtlinien</td></tr></table></div></body></html>
|
||
| doc/html/ch04s06.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.6. Dokumentation erstellen</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Stil-Richtlinien"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.6. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="4.6. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.6. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.6.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.6.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™
|
||
|
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.
|
||
|
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen
|
||
|
Editor nutzt, der spezielle Unterstützung für
|
||
|
<span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den
|
||
|
<a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML
|
||
|
Editor</a>, der bei nicht kommerzieller Nutzung kostenlos
|
||
|
ist.</p></div><div class="sect2" title="4.6.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.6.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass
|
||
|
ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden
|
||
|
dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML
|
||
|
erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script
|
||
|
<span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene
|
||
|
Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt
|
||
|
werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a>
|
||
|
in einer halbwegs aktuellen Version</p></li><li class="listitem"><p>Das Java-Build-System <a class="ulink" href="http://ant.apache.org/" target="_top">Apache Ant</a>
|
||
|
</p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für
|
||
|
<span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung
|
||
|
diverser Stylesheets und Grafiken zur Konvertierung von
|
||
|
<span class="productname">DocBook</span>™ XML in andere Formate. Das
|
||
|
Paket, das benötigt wird, ist zum Zeitpunkt der
|
||
|
Dokumentationserstellung
|
||
|
<code class="filename">dobudish-nojre-1.1.4.zip</code>, aus auf <a class="ulink" href="http://code.google.com/p/dobudish/downloads/list" target="_top">code.google.com</a>
|
||
|
bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment
|
||
|
sind auf allen gängigen Plattformen verfügbar. Beispiel für
|
||
|
Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis
|
||
|
<code class="filename">doc/build</code> entpackt werden. Beispiel unter der
|
||
|
Annahme, das <span class="productname">Dobudish</span>™ in
|
||
|
<code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build
|
||
|
unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.6.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.6.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der
|
||
|
benötigten Software mit einem einfachen Aufruf direkt aus dem
|
||
|
kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.6.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.6.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und
|
||
|
HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass
|
||
|
nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut
|
||
|
und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw.
|
||
|
symbolischen Links gehören hingegen nicht in das Repository.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">4.5. Stil-Richtlinien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
|
||
|
<title>4.6. Stil-Richtlinien</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"><link rel="next" href="ch04s07.html" title="4.7. Dokumentation erstellen"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.6. Stil-Richtlinien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.6. Stil-Richtlinien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.style-guide"></a>4.6. Stil-Richtlinien</h2></div></div></div><p>Die folgenden Regeln haben das Ziel, den Code möglichst gut les-
|
||
|
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich
|
||
|
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden
|
||
|
wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das
|
||
|
Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher
|
||
|
überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere
|
||
|
nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen
|
||
|
verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {
|
||
|
if ($flag) {
|
||
|
# do something with $row
|
||
|
}
|
||
|
|
||
|
if ($use_modules) {
|
||
|
$row->{modules} = MODULE->retrieve(
|
||
|
id => $row->{id},
|
||
|
date => $use_now ? localtime() : $row->{time},
|
||
|
);
|
||
|
}
|
||
|
|
||
|
$report->add($row);
|
||
|
}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen
|
||
|
Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {
|
||
|
...
|
||
|
}</pre><p>oder</p><pre class="programlisting">if ($form->{item_rows} > 0) {
|
||
|
...
|
||
|
}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie
|
||
|
der Befehl / die öffnende schließende Klammer, die den Block
|
||
|
gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen
|
||
|
Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>",
|
||
|
"<code class="function">elsif</code>", "<code class="function">while</code>" befinden
|
||
|
sich auf der gleichen Zeile wie schließende geschweifte Klammern.
|
||
|
Beispiele:</p><pre class="programlisting">if ($form->{sum} > 1000) {
|
||
|
...
|
||
|
} elsif ($form->{sum} > 0) {
|
||
|
...
|
||
|
} else {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
do {
|
||
|
...
|
||
|
} until ($a > 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern
|
||
|
versehen werden. Davon nicht betroffen sind interne Perl-Funktionen,
|
||
|
und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug->message("Could not find file.");
|
||
|
%options = map { $_ => 1 } grep { !/^#/ } @config_file;</pre></li><li class="listitem"><p>Verschiedene Klammern, Ihre Ausdrücke und Leerzeichen:</p><p>Generell gilt: Hashkeys und Arrayindices sollten nicht durch
|
||
|
Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig,
|
||
|
Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form->{debug} == 1) && ($form->{sum} - 100 < 0)) {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
$array[$i + 1] = 4;
|
||
|
$form->{sum} += $form->{"row_$i"};
|
||
|
$form->{ $form->{index} } += 1;
|
||
|
|
||
|
map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;</pre></li><li class="listitem"><p>Mehrzeilige Befehle</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Werden die Parameter eines Funktionsaufrufes auf mehrere
|
||
|
Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt
|
||
|
werden, in der die ersten Funktionsparameter in der ersten Zeile
|
||
|
stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh->prepare("SELECT * FROM some_table WHERE col = ?",
|
||
|
$form->{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Oprator "?:", der am
|
||
|
besten in einer übersichtlichen Tabellenstruktur organisiert
|
||
|
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form->{"row_$i"} ? $i
|
||
|
: $form->{oldcount} ? $form->{oldcount} + 1
|
||
|
: $form->{rowcount} - $form->{rowbase};</pre></li></ol></div></li><li class="listitem"><p>Kommentare</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Kommentare, die alleine in einer Zeile stehen, sollten
|
||
|
soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich
|
||
|
formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte
|
||
|
auf Englisch zu verfassen. So wie ich keine Lust habe,
|
||
|
französischen Quelltext zu lesen, sollte auch der kivitendo
|
||
|
Quelltext für nicht-Deutschsprachige lesbar sein.
|
||
|
Beispiel:</p><pre class="programlisting">my $found = 0;
|
||
|
while (1) {
|
||
|
last if $found;
|
||
|
|
||
|
# complicated check
|
||
|
$found = 1 if //
|
||
|
}
|
||
|
|
||
|
$i = 0 # initialize $i
|
||
|
$n = $i; # save $i
|
||
|
$i *= $const; # do something crazy
|
||
|
$i = $n; # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die
|
||
|
Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form->{sum} = 0;
|
||
|
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
||
|
$some_hash{42} = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen
|
||
|
unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber
|
||
|
wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in
|
||
|
grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion
|
||
|
<code class="function">print_options</code> aus
|
||
|
<code class="filename">bin/mozilla/io.pl</code> angeführt.</p></li><li class="listitem"><p>Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind
|
||
|
unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs
|
||
|
verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur
|
||
|
Entfernung von trailing whitespace. Emacs kennt das Kommande
|
||
|
<span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche
|
||
|
manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au
|
||
|
BufWritePre * :%s/\s\+$//e</code> wird das an Speichern
|
||
|
gebunden.</p></li><li class="listitem"><p>Es wird kein <span class="command"><strong>perltidy</strong></span> verwendet.</p><p>In der Vergangenheit wurde versucht,
|
||
|
<span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen
|
||
|
Stil zu erlangen. Es hat sich aber gezeigt, dass
|
||
|
<span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was
|
||
|
Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für
|
||
|
den Interessierten sind hier die
|
||
|
<span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen
|
||
|
Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm
|
||
|
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79
|
||
|
-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p>
|
||
|
<code class="varname">STDERR</code> ist tabu. Unkonditionale
|
||
|
Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code>
|
||
|
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen
|
||
|
Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode
|
||
|
"<code class="function">message</code>" nimmt als ersten Paramter außerdem
|
||
|
eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer
|
||
|
angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden
|
||
|
und werden in den meisten Fällen auch vom Repository
|
||
|
zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p>
|
||
|
<code class="varname">$form</code>, <code class="varname">$auth</code>,
|
||
|
<code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und
|
||
|
<code class="varname">%myconfig</code> werden derzeit aus dem main package
|
||
|
importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen
|
||
|
Konstrukte sollten lexikalisch lokal gehalten werden.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.5. Die kivitendo-Test-Suite </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.7. Dokumentation erstellen</td></tr></table></div></body></html>
|
||
| doc/html/ch04s07.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.7. Dokumentation erstellen</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s06.html" title="4.6. Stil-Richtlinien"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.7. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="4.7. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.7. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.7.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.7.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™
|
||
|
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.
|
||
|
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen
|
||
|
Editor nutzt, der spezielle Unterstützung für
|
||
|
<span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den
|
||
|
<a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML
|
||
|
Editor</a>, der bei nicht kommerzieller Nutzung kostenlos
|
||
|
ist.</p></div><div class="sect2" title="4.7.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.7.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass
|
||
|
ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden
|
||
|
dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML
|
||
|
erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script
|
||
|
<span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene
|
||
|
Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt
|
||
|
werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a>
|
||
|
in einer halbwegs aktuellen Version</p></li><li class="listitem"><p>Das Java-Build-System <a class="ulink" href="http://ant.apache.org/" target="_top">Apache Ant</a>
|
||
|
</p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für
|
||
|
<span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung
|
||
|
diverser Stylesheets und Grafiken zur Konvertierung von
|
||
|
<span class="productname">DocBook</span>™ XML in andere Formate. Das
|
||
|
Paket, das benötigt wird, ist zum Zeitpunkt der
|
||
|
Dokumentationserstellung
|
||
|
<code class="filename">dobudish-nojre-1.1.4.zip</code>, aus auf <a class="ulink" href="http://code.google.com/p/dobudish/downloads/list" target="_top">code.google.com</a>
|
||
|
bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment
|
||
|
sind auf allen gängigen Plattformen verfügbar. Beispiel für
|
||
|
Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis
|
||
|
<code class="filename">doc/build</code> entpackt werden. Beispiel unter der
|
||
|
Annahme, das <span class="productname">Dobudish</span>™ in
|
||
|
<code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build
|
||
|
unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.7.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.7.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der
|
||
|
benötigten Software mit einem einfachen Aufruf direkt aus dem
|
||
|
kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.7.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.7.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und
|
||
|
HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass
|
||
|
nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut
|
||
|
und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw.
|
||
|
symbolischen Links gehören hingegen nicht in das Repository.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">4.6. Stil-Richtlinien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
|
||
| doc/html/index.html | ||
|---|---|---|
|
<title>kivitendo: Installation, Konfiguration, Entwicklung</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo: Installation, Konfiguration, Entwicklung"><link rel="next" href="ch01.html" title="Kapitel 1. Aktuelle Hinweise"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">kivitendo: Installation, Konfiguration, Entwicklung</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch01.html">Weiter</a></td></tr></table><hr></div><div lang="de" class="book" title="kivitendo: Installation, Konfiguration, Entwicklung"><div class="titlepage"><div><div><h1 class="title"><a name="kivitendo-documentation"></a>kivitendo: Installation, Konfiguration, Entwicklung</h1></div></div><hr></div><div class="toc"><p><b>Inhaltsverzeichnis</b></p><dl><dt><span class="chapter"><a href="ch01.html">1. Aktuelle Hinweise</a></span></dt><dt><span class="chapter"><a href="ch02.html">2. Installation und Grundkonfiguration</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch02.html#Ben%C3%B6tigte-Software-und-Pakete">2.1. Benötigte Software und Pakete</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02.html#Betriebssystem">2.1.1. Betriebssystem</a></span></dt><dt><span class="sect2"><a href="ch02.html#Pakete">2.1.2. Pakete</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s02.html">2.2. Manuelle Installation des Programmpaketes</a></span></dt><dt><span class="sect1"><a href="ch02s03.html">2.3. kivitendo-Konfigurationsdatei</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s03.html#config.config-file.introduction">2.3.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch02s03.html#config.config-file.sections-parameters">2.3.2. Abschnitte und Parameter</a></span></dt><dt><span class="sect2"><a href="ch02s03.html#config.config-file.prior-versions">2.3.3. Versionen vor 2.6.3</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s04.html">2.4. Anpassung der PostgreSQL-Konfiguration</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s04.html#Zeichens%C3%A4tze-die-Verwendung-von-UTF-8">2.4.1. Zeichensätze/die Verwendung von UTF-8</a></span></dt><dt><span class="sect2"><a href="ch02s04.html#%C3%84nderungen-an-Konfigurationsdateien">2.4.2. Änderungen an Konfigurationsdateien</a></span></dt><dt><span class="sect2"><a href="ch02s04.html#Erweiterung-f%C3%BCr-servergespeicherte-Prozeduren">2.4.3. Erweiterung für servergespeicherte Prozeduren</a></span></dt><dt><span class="sect2"><a href="ch02s04.html#Datenbankbenutzer-anlegen">2.4.4. Datenbankbenutzer anlegen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s05.html">2.5. Webserver-Konfiguration</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s05.html#d0e492">2.5.1. Grundkonfiguration mittels CGI</a></span></dt><dt><span class="sect2"><a href="ch02s05.html#Apache-Konfiguration.FCGI">2.5.2. Konfiguration für FastCGI/FCGI</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s06.html">2.6. Der Task-Server</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s06.html#Konfiguration-des-Task-Servers">2.6.1. Verfügbare und notwendige Konfigurationsoptionen</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#Einbinden-in-den-Boot-Prozess">2.6.2. Automatisches Starten des Task-Servers beim Booten</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#Prozesskontrolle">2.6.3. Wie der Task-Server gestartet und beendet wird</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#Prozesskontrolle2">2.6.4. Task-Server mit mehreren Mandanten</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s07.html">2.7. Benutzerauthentifizierung und Administratorpasswort</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s07.html#Grundlagen-zur-Benutzerauthentifizierung">2.7.1. Grundlagen zur Benutzerauthentifizierung</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Administratorpasswort">2.7.2. Administratorpasswort</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Authentifizierungsdatenbank">2.7.3. Authentifizierungsdatenbank</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Passwort%C3%BCberpr%C3%BCfung">2.7.4. Passwortüberprüfung</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Name-des-Session-Cookies">2.7.5. Name des Session-Cookies</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Anlegen-der-Authentifizierungsdatenbank">2.7.6. Anlegen der Authentifizierungsdatenbank</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s08.html">2.8. Benutzer- und Gruppenverwaltung</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s08.html#Zusammenh%C3%A4nge">2.8.1. Zusammenhänge</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Datenbanken-anlegen">2.8.2. Datenbanken anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Gruppen-anlegen">2.8.3. Gruppen anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Benutzer-anlegen">2.8.4. Benutzer anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Gruppenmitgliedschaften-verwalten">2.8.5. Gruppenmitgliedschaften verwalten</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Migration-alter-Installationen">2.8.6. Migration alter Installationen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s09.html">2.9. Drucken mit kivitendo</a></span></dt><dt><span class="sect1"><a href="ch02s10.html">2.10. OpenDocument-Vorlagen</a></span></dt><dt><span class="sect1"><a href="ch02s11.html">2.11. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung:
|
||
|
EUR</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s11.html#config.eur.introduction">2.11.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch02s11.html#config.eur.parameters">2.11.2. Konfigurationsparameter</a></span></dt><dt><span class="sect2"><a href="ch02s11.html#config.eur.setting-parameters">2.11.3. Festlegen der Parameter</a></span></dt><dt><span class="sect2"><a href="ch02s11.html#config.eur.inventory-system-perpetual">2.11.4. Bemerkungen zu Bestandsmethode</a></span></dt><dt><span class="sect2"><a href="ch02s11.html#config.eur.knonw-issues">2.11.5. Bekannte Probleme</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s12.html">2.12. SKR04 19% Umstellung für innergemeinschaftlichen Erwerb</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s12.html#config.skr04-update-3804.introduction">2.12.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch02s12.html#config.skr04-update-3804.create-chart">2.12.2. Konto 3804 manuell anlegen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s13.html">2.13. kivitendo ERP verwenden</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch03.html">3. Features und Funktionen</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch03.html#features.periodic-invoices">3.1. Wiederkehrende Rechnungen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch03.html#features.periodic-invoices.introduction">3.1.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch03.html#features.periodic-invoices.configuration">3.1.2. Konfiguration</a></span></dt><dt><span class="sect2"><a href="ch03.html#features.periodic-invoices.reports">3.1.3. Auflisten</a></span></dt><dt><span class="sect2"><a href="ch03.html#features.periodic-invoices.task-server">3.1.4. Erzeugung der eigentlichen Rechnungen</a></span></dt><dt><span class="sect2"><a href="ch03.html#features.periodic-invoices.create-for-current-month">3.1.5. Erste Rechnung für aktuellen Monat erstellen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch03s02.html">3.2. Dokumentenvorlagen und verfügbare Variablen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.einf%C3%BChrung">3.2.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.variablen-ausgeben">3.2.2. Variablen ausgeben</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.verwendung-in-druckbefehlen">3.2.3. Verwendung in Druckbefehlen</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.tag-style">3.2.4. Anfang und Ende der Tags verändern</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.zuordnung-dateinamen">3.2.5. Zuordnung von den Dateinamen zu den Funktionen</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.dateinamen-erweitert">3.2.6. Sprache, Drucker und E-Mail</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.allgemeine-variablen">3.2.7. Allgemeine Variablen, die in allen Vorlagen vorhanden
|
||
|
sind</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.invoice">3.2.8. Variablen in Rechnungen</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.dunning">3.2.9. Variablen in Mahnungen und Rechnungen über Mahngebühren</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.andere-vorlagen">3.2.10. Variablen in anderen Vorlagen</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.bloecke">3.2.11. Blöcke, bedingte Anweisungen und Schleifen</a></span></dt><dt><span class="sect2"><a href="ch03s02.html#dokumentenvorlagen-und-variablen.markup">3.2.12. Markup-Code zur Textformatierung innerhalb von
|
||
|
Formularen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch03s03.html">3.3. Excel-Vorlagen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch03s03.html#excel-templates.summary">3.3.1. Zusammenfassung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.usage">3.3.2. Bedienung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.syntax">3.3.3. Variablensyntax</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.limitations">3.3.4. Einschränkungen</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ch04.html">4. Entwicklerdokumentation</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch04.html#devel.globals">4.1. Globale Variablen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04.html#d0e4348">4.1.1. Wie sehen globale Variablen in Perl aus?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4449">4.1.2. Warum sind globale Variablen ein Problem?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4482">4.1.3. Kanonische globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4862">4.1.4. Ehemalige globale Variablen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s02.html">4.2. Entwicklung unter FastCGI</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.general">4.2.1. Allgemeines</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.exiting">4.2.2. Programmende und Ausnahmen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.globals">4.2.3. Globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.performance">4.2.4. Performance und Statistiken</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.known-issues">4.2.5. Bekannte Probleme</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s03.html">4.3. SQL-Upgradedateien</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.introduction">4.3.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.format">4.3.2. Format der Kontrollinformationen</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.dbupgrade-tool">4.3.3. Hilfsscript dbupgrade2_tool.pl</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s04.html">4.4. Translations and languages</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s04.html#translations-languages.introduction">4.4.1. Introduction</a></span></dt><dt><span class="sect2"><a href="ch04s04.html#translations-languages.file-structure">4.4.2. File structure</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s05.html">4.5. Stil-Richtlinien</a></span></dt><dt><span class="sect1"><a href="ch04s06.html">4.6. Dokumentation erstellen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s06.html#devel.build-doc.introduction">4.6.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s06.html#devel.build-doc.required-software">4.6.2. Benötigte Software</a></span></dt><dt><span class="sect2"><a href="ch04s06.html#devel.build-doc.build">4.6.3. PDFs und HTML-Seiten erstellen</a></span></dt><dt><span class="sect2"><a href="ch04s06.html#devel.build-doc.repository">4.6.4. Einchecken in das Git-Repository</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch01.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Kapitel 1. Aktuelle Hinweise</td></tr></table></div></body></html>
|
||
|
Formularen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch03s03.html">3.3. Excel-Vorlagen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch03s03.html#excel-templates.summary">3.3.1. Zusammenfassung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.usage">3.3.2. Bedienung</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.syntax">3.3.3. Variablensyntax</a></span></dt><dt><span class="sect2"><a href="ch03s03.html#excel-templates.limitations">3.3.4. Einschränkungen</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ch04.html">4. Entwicklerdokumentation</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch04.html#devel.globals">4.1. Globale Variablen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04.html#d0e4348">4.1.1. Wie sehen globale Variablen in Perl aus?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4449">4.1.2. Warum sind globale Variablen ein Problem?</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4482">4.1.3. Kanonische globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04.html#d0e4862">4.1.4. Ehemalige globale Variablen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s02.html">4.2. Entwicklung unter FastCGI</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.general">4.2.1. Allgemeines</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.exiting">4.2.2. Programmende und Ausnahmen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.globals">4.2.3. Globale Variablen</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.performance">4.2.4. Performance und Statistiken</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#devel.fcgi.known-issues">4.2.5. Bekannte Probleme</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s03.html">4.3. SQL-Upgradedateien</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.introduction">4.3.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.format">4.3.2. Format der Kontrollinformationen</a></span></dt><dt><span class="sect2"><a href="ch04s03.html#db-upgrade-files.dbupgrade-tool">4.3.3. Hilfsscript dbupgrade2_tool.pl</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s04.html">4.4. Translations and languages</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s04.html#translations-languages.introduction">4.4.1. Introduction</a></span></dt><dt><span class="sect2"><a href="ch04s04.html#translations-languages.file-structure">4.4.2. File structure</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s05.html">4.5. Die kivitendo-Test-Suite</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.intro">4.5.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.prerequisites">4.5.2. Voraussetzungen</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.execution">4.5.3.
|
||
|
Existierende Tests ausführen
|
||
|
</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.meaning_of_scripts">4.5.4.
|
||
|
Bedeutung der verschiedenen Test-Scripte
|
||
|
</a></span></dt><dt><span class="sect2"><a href="ch04s05.html#devel.testsuite.create_new">4.5.5.
|
||
|
Neue Test-Scripte erstellen
|
||
|
</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch04s06.html">4.6. Stil-Richtlinien</a></span></dt><dt><span class="sect1"><a href="ch04s07.html">4.7. Dokumentation erstellen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.introduction">4.7.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.required-software">4.7.2. Benötigte Software</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.build">4.7.3. PDFs und HTML-Seiten erstellen</a></span></dt><dt><span class="sect2"><a href="ch04s07.html#devel.build-doc.repository">4.7.4. Einchecken in das Git-Repository</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch01.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Kapitel 1. Aktuelle Hinweise</td></tr></table></div></body></html>
|
||
| t/README | ||
|---|---|---|
|
Testsuite for Lx-Office.
|
||
|
|
||
|
These tests are a means to ensure basic sanity among the lx-office source
|
||
|
files. The test framework was originally written by the guys of Bugzilla, and
|
||
|
has been modified to cope with the Lx-Office structure.
|
||
|
|
||
|
To run a full test use the shell script t/test.sh.
|
||
|
You can also run every test with the perl interpreter like this:
|
||
|
|
||
|
$ perl t/001compile.t
|
||
|
|
||
|
A makefile for an automated make test would be highly appreciated.
|
||
|
|
||
|
|
||
|
|
||
|
The Tests:
|
||
|
|
||
|
001compile.t: Tries to compile every source file. Bails out if any errors occur.
|
||
|
002goodperl.t: Checks every perl source file for taint, warnings and strict.
|
||
|
While taint is not seen mandatory, warnings and strict are.
|
||
|
003safesys: Checks is system() and exec() calls are fully qualified.
|
||
|
004template.t defunct!
|
||
|
005no_tabs.t checks every file for the \t Tab char. don't use tabs please.
|
||
|
006spelling.t checks for common spelling errors.
|
||
|
011pod.t checks if POD syntax is correct.
|
||
|
|
||
|
|
||
|
Wanted Tests:
|
||
|
|
||
|
- module check
|
||
|
- check if symlinks are missing.
|
||
|
- check for anything outside lower ascii in pl/pm files (only place for complex
|
||
|
coding is locale)
|
||
|
- check for msdos line endings
|
||
|
- check for trailing whitespace
|
||
|
- Devise a test to check if there are modifications to locales without a
|
||
|
locales.pl run.
|
||
|
- Test if parse_template can compile all html templates.
|
||
|
|
||
|
and later:
|
||
|
- spec tests for pure backend modules like Form.pm and Common.pm
|
||
Auch abrufbar als: Unified diff
Doku: Test-Doku aus t/README in die Haupt-Doku überführt & erweitert