[Dresden-pm] Pakete war: Frage zum Testen (Regressionstests)

[Hans-Dietrich Kirmse]

Hallo,

Steffen Schwigon schrieb:

> Vielleicht noch als Zusatz zu den anderen Antworten:
> 
> Es hilft, wenn Du Dein Modul in eine CPAN-konforme Struktur verpackst,
> d.h. Verzeichnisse und Dateien nach einer gewissen Konvention anlegst.
> 
> Darin gibt es auch eine Konvention, wo und wie zu der Distribution
> gehörige Testscripte stehen sollten.

über dieses Problem habe ich schonmal (leider ohne Lösung) nachgedacht.

Es geht um 8 CGI-Scripte, bei der ich alle Subroutinen in ein
Modul ausgelagert habe. Alle Konfigurationsdaten sind in einer
Datei ausgelagert. Dann gibt es noch ein Template und das war's.
Es ist eine spezielle Lösung für den speziellen Schulserver
Arktur 4. Geht aber m.E. leicht anzupassen auf andere Linux-
Schulserver.

jetzt mein Problem: in einem CPAN-Archiv sind doch immer nur
Module und keine CGI-Scripte (zumindest habe ich das so verstanden).
Wenn ich nur meine pm-Datei (also das Modul) nehme, dann macht das
aber kein Sinn, weil die Scripte und das Modul einfach zusammen
gehören. m.E. passt da das "Muster" CPAN überhaupt nicht.

die Pakete für Arktur sind solche Pakete wie bei Slackware
(also einfache tar.gz-Files). Nehme ich SuSE, dann haben die
rpm-Pakete. Und es wird natürlich gewünscht, dass alle Software
NICHT am Paketmanager vorbei installiert wird.

am liebsten wäre mir, wenn es eine Lösung gäbe nach folgenden
Muster: "CPAN-Paket" (was nicht auf dem CPAN liegen muss) und mit
einem Script wird das auf Wunsch in ein RPM-File konvertiert oder
als Slackware-Paket.

> Der Vorteil ist, dass Du dann mit dem Build-Mechanismus einfach ein
> "./Build test" machen kannst, was die beschriebenen Lösungen der
> anderen mit Test::Harness usw. implizit ausführt.

alles was "make & Co." (und damit sicher auch "Build") betrifft, habe
ich eh noch nicht verstanden (hier ausdrücklich den Sinn dieser Sache
bei Perl. bei C-Programmen sehe ich den Sinn schon).

die wenigen Module, die ich vom CPAN genutzt habe, habe ich bis jetzt
einfach in das entsprechende Verzeichnis (auf meinem Windows-Rechner)
kopiert und das lief bis jetzt immer.

> Zum Bauen einer Distribution zu einem Modul gab es mal einen kleinen
> Thread hier in der Liste. Vielleicht kannst Du damit ja etwas
> anfangen. Beginne hier:
> 
>   http://mail.pm.org/pipermail/dresden-pm/2005-July/000870.html

an diesen Thread kann ich mich erinnern. Aber er beschreibt (sicherlich
wichtige Punkte) des Vorgehens, mir mangelt es am Verständnis für das
eigentliche Konzept.

> Wenn Dein Modul bereits zu groß und zu anders strukturiert ist, kann
> es beim Einstieg schwer werden. Dann bau Dir erstmal ein Minimodul
> (z.B. Acme::ProbierAffe), was nur eine triviale Funktion enthält und
> mach dann daraus eine CPAN-typische Distribution.

Das ist mein Problem: ich habe eigentlich CGI-Scripte. Die Prozeduren
habe ich eigentlich nur herausgezogen, um mehrfach verwendete
Subroutinen auch nur einmal bereitzustellen und damit nur einmal
"pflegen" zu müssen. Wegen dem Testen und der Verschlankung der
eigentlichen CGI-Scripte habe ich inzwischen alle Subroutinen in
dieses Modul geschoben. Aber das ist doch niemals CPAN-kompatibel.
Aber wie erstelle ich jetzt sinnvoll ein Paket. Noch schlimmer:
meine Lösung kommt in ein spezielles Verzeichnis vom Webserver. Aber
dort gehören die test-Dateien niemals hin. - aber andererseits wollen
diese vielleicht einige (wenige) Admins doch wenigstens ansehen. mir
fehlt einfach momentan das/ein Konzept.

könntet ihr mich bitte noch mal erleuchten  ;)

Mit freundlichen Grüßen
Hans-Dietrich