Skip to content

Latest commit

 

History

History
494 lines (278 loc) · 9.82 KB

gpw10talk-cpantesters.pod

File metadata and controls

494 lines (278 loc) · 9.82 KB

Hat das jemand getestet?

Andreas König, DPW10, RRZE, Erlangen, 2008-02-13

Der Alltag eines CPAN Testers

21:45 < nadim> history | wc -l => 500
21:46 < nadim> history | grep test | wc -l => 375
21:46 < nadim> I have to get a life!

Was ist ein CPAN Tester?

  • CPAN.pm + CPAN::Reporter + Konfiguration

  • o conf init /report/

  • test Foo::Bar::Baz

    Side effect reporting

  • report Foo::Bar::Baz

    Casual reporting

  • CPAN::Reporter::Smoker

    Von David Golden - Turnkey CPAN Testers smoking

Konfigurieren

    CPAN::Reporter schreibt das Ergebnis der interaktiven Konfiguration in die Datei ~/.cpanreporter/config.ini. Im INI Format.

    cc_author=ask/no
debug=1
edit_report=ask/no
editor=emacsclient
email_from=andreas.koenig.gmwojprw@franz.ak.mind.de
send_duplicates=ask/no
send_report=ask/no
smtp_server=localhost

    Seit 1.08 auch: cc_skipfile, send_skipfile

Old school

  • CPANPLUS

  • CPAN::YACSmoke

    Der erste Smoker von Barbie.

  • POE::Component::CPAN::YACSmoke

    Hochleistungs-Smoker unter POE von Bingos (Chris Williams)

Datentransport

  • Test::Reporter

    von beiden Systemen zur Einlieferung der Daten auf dem zentralen cpantesters Server verwendet. Von Adam J. Foxson

  • CPAN::Testers

    Kein Modul, lediglich eine manpage, die die Datenflüsse darstellt

  • testers-over-http-upload

    Work in progress. Wird in Test::Reporter entsprechnd reflektiert werden.

Datenpool

  • sammelt Daten über first hand experiences

Warum teste ich?

  • um Bugs zu finden, bevor ich als Enduser auf sie treffe

  • in Modulen

  • in Perl

  • weil es Spaß macht

  • weil es dem Ruf unseres CPAN gut tut

  • weil es eine Menge dabei zu entdecken gibt

  • weil ich dabei den Autoren etwas zurückgeben kann

    Etwa Test::Harness durchtesten.

Wann scheitert das Testen?

  • Wenn Entwickler und Tester nicht miteinander können

  • Ovid:

    I find it sad that so many companies have this tension between QA and developers and here we are seeing the EXACT same thing.

    http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-01/msg00722.html

    In dem Thread, in dem Ovid das gesagt hat, sind Emotionen hochgekocht, die für mich schwer nachvollziehbar sind. Es kommt offensichtlich beim Aufeinandertreffen von göttlichen Entwicklern und dem undankbaren, stets nur auf seinen eigenen Vorteil bedachten, schmarotzendem Pöbel zu existenziellen Grundfragen.

Wann scheitert das Testen außerdem?

  • Wenn Tester zu viele schlechte Reports abliefern

    Marc Lehmann ist das wohl passiert und er hat wohl einen Autoresponder für cpantesters eingerichtet, der gewisse Mails von cpantesters postwendend zurückschickt.

  • Andy Armstrong

    I'm locked in correspondence with Marc now.

    His view: cpan-testers are incompetent, ego tripping, quasi-religious nuisances.

Fehler im Testsystem

  • Traditionelle, manuelle Bugreports

    sind immer vorzuziehen, wenn man ein Problem analysiert hat und weiss, wovon man redet.

  • Automatisierte Testreports

    sind immer nur Daten und enthalten hoffentlich genug Hinweise über die Natur von PASSes und FAILs. Sie können anderen helfen, sich ein Bild zu machen, sie ersetzen aber nicht die Analyse.

Kommunikationsgau

    Oft kommt es nicht vor. Aber man sollte damit rechnen.

    Wenn ein Tester kein Interesse an unseren Diensten hat, hands down. Ab in den Killfile.

    Wenn dann noch etwas offen ist, einen Patch schreiben, eine Distroprefs-Datei zu schreiben, höchstens eine kurze Notiz an den Autor.

    Wenn wir als Tester Autoren nerven, war alle Mühe vergeblich.

Grenzfälle

  • Schlechte Tests sind relativ harmlos

    Tests, die Bugs anzeigen, wo keine sind oder die existierende Bugs nicht anzeigen, stellen nicht den Vorang des Testens in Frage. Es ist halt dann eine frage der Zet, bis jemand die schlechten Tests identifiziert.

Grenzfälle II

  • Random Test Results

    Zusätzliche Buchführung kann manchmal helfen, zufällige Testergebnisse zu identifizieren. Wer immer wieder die gleichen Module testet, liefert über CPAN::Reporter immer höchstens einen PASS und eine FAIL pro perl Version ab. Wenn die Tests aber 150 PASS und 50 FAIL ergeben...

    http://rt.cpan.org/Ticket/Display.html?id=28122

  • Overeager Testing

    Es gibt Tests, die laufen zu lange. So what?

Grenzfälle II

  • Hänger

    Es gibt Tests, die bleiben einfach stehen. Wer mit Bingo's POE Server arbeitet, kennt das Problem nicht. Andere müssen entscheiden, ob der Prozess auf Input wartet und entsprechend antworten, und dann später eine Distroprefs-Datei schreiben; oder ob sie die Distribution überspringen wollen und sie in einen Exclude-File aufnehmen.

    Environment Variable setzen: PERL_MM_USE_DEFAULT=1 und AUTOMATED_TESTING=1. Smoker machen das automatisch.

Howto Use Your {Makefile,Build}.PL

  • Makefile.PL: require 5.008

    Rule out old perl versions

  • Build.PL: requires => { perl => 5.008 }

    Same thing

  • Devel-CheckLib

    check that a library is available

  • Devel-CheckOS

    check what OS we're running on

  • Notbremse: exit 0, ohne einen Makefilezu schreiben

Grades

  • PASS

    distribution built and tested correctly

  • FAIL

    distribution failed to build or test correctly

  • UNKNOWN

    distribution built, but had no test suite or outcome was inconclusive

  • NA

    distribution is not applicable to this platform and/or version of Perl

  • "invalid"

    Not really a grade. Dependency has failed, no report shall be sent

URLs

URLs

URLs

URLs

  • http://www.nntp.perl.org/group/perl.cpan.testers/

    Hier kommen die Testreports zuerst an. Einmal stündlich werden neue Seiten generiert. Solange muß der Autor warten, wenn wir als Tester ihm kein CC geschickt haben.

    Im Januar wurde der einmillionste Testreport von David Cantrell eingeliefert.

    http://www.nntp.perl.org/group/perl.cpan.testers/2008/01/page1.html

http://www.nntp.perl.org/group/perl.cpan.testers/2008/01/page84.html

http://use.perl.org/~BinGOs/journal/35550

    Bis vor wenigen Tagen eine Mailingliste, jetzt nicht mehr subscribierbar.

URLs

  • http://cpandeps.cantrell.org.uk/?module=

    Kurz vor der letzten YAPC in Wien hat David Cantrell sich dieses Kleinod ausgedaecht. Anhand der META.yml Dateien, die heutzutage bei den meisten Distributionen dabei sind, malt er eine Art Dependency Graphen und berechnet anhand der aktuellen FAIL Quoten die Gesamtwahrscheinlichkeit aus, daß ein Modul mit Erfolg getestet werden kann.

  • http://cpandeps.cantrell.org.uk/?module=Jifty

URLs

URLs

  • http://perl.grango.org/

    Hier sammelt Barbie seine Statistiken. Hier ist auch die Hall Of Fame der größten Tester aller Zeiten.

URLs

Mailing lists

Mailing lists

Mailing lists

Mailing lists

RT

  • http://rt.cpan.org/

    Ich mag RT als Bug Tracking System. Die Fähigkeit, die meisten Arbeiten per Email zu erledigen, das REST Interface, die klaren URLs,die man leicht nachbauen kann, das alles macht es zu einem guten Partner in der täglichen Arbeit.

  • http://use.perl.org/~LaPerla/journal/35252

    Zu Sylvester als Neujahrsgruß entstanden, um einmal herauszufinden, wie dieses RT denn eigentlich zu über 30000 Bugreport in nur 6 Jahren gekommen ist.

Hat das jemand getestet?

Ja

Aber hat das auch jemand richtig getestet?