Revision 42298d2c
Von Moritz Bunkus vor fast 6 Jahren hinzugefügt
| doc/html/ch04s06.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<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 3.5.3: 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
|
||
|
}
|
||
|
<title>4.6. 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 3.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Translations and languages"><link rel="next" href="ch04s07.html" title="4.7. 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. Die kivitendo-Test-Suite</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. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.6. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.6.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.6.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">t/</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">t/</code>, deren Dateiname
|
||
|
auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.6.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.6.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:
|
||
|
<code class="literal">perl-Test-Deep</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Deep</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Exception</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-exception-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Exception</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Exception</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Output</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-output-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Output</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Output</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Harness</code> 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 <a class="ulink" href="http://www.cpan.org" target="_top">CPAN</a> bezogen werden.</p></li><li class="listitem"><p>
|
||
|
<code class="literal">LWP::Simple</code> aus dem Paket
|
||
|
<code class="literal">libwww-perl</code> (Debian-Panetname:
|
||
|
<code class="literal">libwww-perl</code>; Fedora:
|
||
|
<code class="literal">perl-libwww-perl</code>; openSUSE:
|
||
|
<code class="literal">perl-libwww-perl</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">URI::Find</code> (Debian-Panetname:
|
||
|
<code class="literal">liburi-find-perl</code>; Fedora:
|
||
|
<code class="literal">perl-URI-Find</code>; openSUSE:
|
||
|
<code class="literal">perl-URI-Find</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Sys::CPU</code> (Debian-Panetname:
|
||
|
<code class="literal">libsys-cpu-perl</code>; Fedora und openSUSE: nicht
|
||
|
vorhanden)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Thread::Pool::Simple</code> (Debian-Panetname:
|
||
|
<code class="literal">libthread-pool-simple-perl</code>; Fedora und
|
||
|
openSUSE: nicht vorhanden)</p></li></ul></div><p>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
|
||
|
<code class="literal">testing/database</code> Datenbankverbindungsparameter
|
||
|
angegeben werden. Der hier angegebene Benutzer muss weiterhin das
|
||
|
Recht haben, Datenbanken anzulegen und zu löschen.</p><p>Der so angegebene Benutzer muss nicht zwingend über
|
||
|
Super-User-Rechte verfügen. Allerdings gibt es einige
|
||
|
Datenbank-Upgrades, die genau diese Rechte benötigen. Für den Fall
|
||
|
kann man in diesem Konfigurationsabschnitt einen weiteren
|
||
|
Benutzeraccount angeben, der dann über Super-User-Rechte verfügt, und
|
||
|
mit dem die betroffenen Upgrades durchgeführt werden. In der
|
||
|
Beispiel-Konfigurationsdatei finden Sie die benötigten
|
||
|
Parameter.</p></div><div class="sect2" title="4.6.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.6.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.pl</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach
|
||
|
nur <code class="filename">t/test.pl</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.pl</code>. Beispielsweise:</p><pre class="programlisting">t/test.pl t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.6.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.6.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.6.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.6.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.6.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.6.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen
|
||
|
testen</h4></div></div></div><p>Ideen, die abgesehen von Funktionen 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.6.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.6.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 sein, 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.6.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.6.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 Operator "?:", 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>
|
||
|
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 </p><pre class="programlisting">Support::TestSetup::login();</pre><p>
|
||
|
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="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. 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.7. Stil-Richtlinien</td></tr></table></div></body></html>
|
||
Auch abrufbar als: Unified diff
Dokumentation: HTML & PDF gebaut