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

[Steffen Schwigon]

Hans-Dietrich Kirmse <hd.kirmse at gmx.de> writes:
> Es geht um 8 CGI-Scripte, bei der ich alle Subroutinen in ein
> Modul ausgelagert habe.
> [...]
> jetzt mein Problem: in einem CPAN-Archiv sind doch immer nur
> Module und keine CGI-Scripte

Keine Sorge, betrachte erstmal das Modul für sich.
Für die CGIs findet sich in der Struktur dann schon ein Platz.


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

Hast Du einmal die Standardstruktur, gibt's dafür Lösungen.


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

Der Sinn ist die uniforme Abarbeitung nach immer dem gleichen Schema:

 - configure
 - make
 - make check
 - make install

bzw.

 - perl Makefile.PL
 - make
 - make test
 - make install

bzw.

 - perl Build.PL
 - ./Build
 - ./Build test
 - ./Build install


Dann kann das Installieren nämlich auch ein Automatismus machen.



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

Der Build-Mechnaismus lohnt sich halt genau für Deine nichttriviale
Verteilung, wenn das Modul irgendwohin gehört und die CGI-Skripte
woandershin und die Manpages noch woandershin. Du musst nie wieder
etwas "in ein entsprechendes Verzeichnis" kopieren. Macht alles die
Distribution, weil sie standardkonform ist.


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

Du musst es mit Acme::ProbierAffe einfach mal durchspielen.

Manches kann man nicht theoretisch verstehen, man muss es "angefasst"
haben. Einmal, zweimal gemacht, dann macht es Klick. Lohnt sich.

Scheib ein Acme::ProbierAffe.


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

Aha. Na prima. Dann kann es sinnvoll sein, nur das Modul, ohne
Skripte, als Distribution zu bauen. Die Skripte bleiben außen vor,
werden autonom "irgendwie" installiert und wenn Du Funktionalität
hinzufügst, dann in das Modul und distributierst nur noch das bei
Updates.


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

Du musst es halt anpassen. Schreib ein Acme::ProbierAffe. :-)
Ist 1-2 Stunden Arbeit beim ersten Mal, vielleicht sogar länger.
Aber Du kommst nicht drumrum. Nutze die URL.


> Noch schlimmer: meine Lösung kommt in ein spezielles Verzeichnis vom
> Webserver.

Das betrifft nicht das Modul, sondern nur die CGI-Skripte. Deswegen
lass sie raus aus der Distribution. Divide and conquer.


> Aber dort gehören die test-Dateien niemals hin. -

Nein, die gehören zum Modul.
Die werden nie installiert.

Dafür gibt's genau die Trennung zwischen

 ./Build
 ./Build test

und

 ./Build install


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

    To follow the path:
    look to the master,
    follow the master,
    walk with the master,
    see through the master,
    become the master.

Ohne probieren wird es nichts. Nach dem "look" kommt das "follow". 

Du musst anfangen Acme::ProbierAffe zu bauen, dann wird Dir das erste
bissel klar, dann Dein Modul und morgen die ganze Welt. :-)


Wenn Du damit konkrete Probleme bekommst, schreibst Du die hier
rein. Die lösen wir schrittweise, teile und herrsche.


GreetinX
Steffen 
-- 
Steffen Schwigon <http://renormalist.net>