Testen von Modulen

Die in diesem Abschnitt beschriebenen Module werden meistens für Tests von anderen Modulen eingesetzt. Sie können aber auch bei Tests von Applikationen eingesetzt.

Test::Harness

Bei Software-Tests ist test harness eine Sammlung von Programmen und Testdaten um ein Programm zu testen. Dies geschieht unter wechselnden Bedingungen und dabei werden die Ergebnisse kontrolliert. Das Perl-Modul Test::Harness übernimmt genau diese Aufgaben: Es startet die Testprogramme und erstellt eine Statistik für die Ergebnisse.

Das Modul bietet auch nur zwei Funktionen:

• runtests
• execute_tests

runtests startet automatisch alle Testskripte, die der Funktion übergeben werden. Ein Beispiel:

  1 #!/usr/bin/perl
  2 use Test::Harness;
  3
  4 my $file = 'example.t';
  5 runtests($file);

Wenn example.t so aussieht:

  1 #!/usr/bin/perl
  2 use Test::More tests => 1;
  3 ok(1 + 1 == 2);

Erhält man folgende Ausgabe:

  C:\community>test_harness.pl
  example....ok  
  All tests successful
  Files=1, Tests=1,  0 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)

Nach dem Start des Programms wird eine Liste ausgegeben, in der für jedes gestartete Testskript angezeigt wird, ob die Tests erfolgreich waren oder nicht. Nach dieser Liste wird die Statistik ausgegeben. In diesem Fall waren alle Tests erfolgreich. Hier wurde 1 Programm gestartet, das einen Test enthielt.

Ein zweites Testskript wird der Testsuite hinzugefügt. Dieses Skript enthält auch wieder einen einfachen Test.

  1 #!/usr/bin/perl
  2 use Test::More tests => 1;
  3 ok(1 + 1 == 3);

Dann sollen beide Testskripte gestartet werden:

  1 #!/usr/bin/perl
  2 use Test::Harness;
  3
  4 my @files = qw(harness_bsp.pl harness_bsp2.pl);
  5 runtests(@files);

Es ist leicht zu erkennen, dass der Test im zweiten Skript fehlschlagen wird. Dieser Test wurde eingefügt, um die Statistik zu zeigen wenn ein Test fehlschlägt. Die Ausgabe bei einem Testlauf sieht dann wie folgt aus:

  ~/entwicklung 33> perl harness_test.pl 
  harness_bsp.....ok                                                           
  harness_bsp2....
  #   Failed test in harness_bsp2.pl at line 3.
  harness_bsp2....NOK 1# Looks like you failed 1 test of 1.                    
  harness_bsp2....dubious                                                      
          Test returned status 1 (wstat 256, 0x100)
  DIED. FAILED test 1
          Failed 1/1 tests, 0.00% okay
  Failed Test     Stat Wstat Total Fail  Failed  List of Failed
  -------------------------------------------------------------------------------
  harness_bsp2.pl    1   256     1    1 100.00%  1
  Failed 1/2 test scripts, 50.00% okay. 1/2 subtests failed, 50.00% okay.

Schon während die Skripte laufen, werden die Tests angezeigt, die fehlschlagen. Hier wird durch das NOK 1 angezeigt, dass in dem Skript harness_bsp2 der Test Nummer 1 fehlschlägt. Ganz unten erscheint dann die Aufstellung, welche Tests in welchen Skripten fehlgeschlagen sind. Hier wird harness_bsp2.pl aufgeführt und am Ende wird auch eine Liste der fehlgeschlagenen Tests ausgegeben.

Zum Schluss wird eine Zusammenfassung ausgegeben, in der aufgeführt wird, dass 1 von 2 Skripte fehlgeschlagen sind und dass 1 von 2 Subtests nicht erfolgreich waren.

Die Funktion execute_tests eignet sich, wenn man eine eigene Statistik erstellen will. Sie liefert zwei Hashreferenzen. Im ersten Hash sind alle Daten zu allen Tests: Wie viele Dateien enthalten sind, wie viele Tests geplant sind, wie viele davon erfolgreich oder fehlgeschlagen sind und noch weitere Informationen. Im zweiten Hash befinden sich die Informationen zu den fehlgeschlagenen Tests. Nach Testskript aufgeschlüsselt finden sich Informationen wie: Welche Tests sind fehlgeschlagen, wie viele Tests geplant waren und noch mehr.

Allerdings ist diese Funktion erst ab Version 2.57 implementiert und mit Perl wird erst aber der Version 5.9.4 mit einer Version > 2.57 ausgeliefert.

Weiterhin gibt es noch drei Parameter zur Konfiguration des Moduls:

Wenn $Test::Harness::verbose auf einen ``wahren'' Wert gesetzt wird, wird die Ausgabe der Testskripte mit ausgegeben. Ansonsten werden nur Daten von STDERR ausgegeben.

Mit $Test::Harness::switches kann man Parameter für den Perl-Interpreter setzen. Standardmäßig wird -w gesetzt.

Wenn $Test::Harness::Timer gesetzt wird und Time::HiRes installiert ist, wird nach jedem Testskript die Laufzeit ausgegeben.

Test::Simple

Der Name ist Programm: Simple. Das Modul ist sehr übersichtlich und bietet nur zwei Funktionalitäten, die für einfache Tests ausreichend sind. Dieses Modul beschränkt sich auf zwei grundlegende Funktionen, die auch in Test::More umgesetzt sind:

Es muss ein Plan angegeben werden, der angibt wie viele Test gemacht werden und ist somit ein Test in sich.

Sonst gibt es nur noch die Funktion ok, mit der einfache Tests gemacht werden können. Als ersten Parameter erwartet die Funktion einen boolschen Wert. Ist der Wert wahr, wird ok ausgegeben, andernfalls ein not ok. Als zweiten Parameter kann ein Name für den Test angegeben werden.

Beispiel:

   1 #!/usr/bin/perl
   2 
   3 use strict;
   4 use warnings;
   5 use Test::Simple tests => 5;
   6 
   7 ok(1,'erfolgreicher Test');
   8 ok(0,'nicht erfolgreicher Test');
   9 ok(1 == 1,'1 gleich 1');
     10 ok(get_number() == 23,'get_number() liefert 23');
     11 ok(get_string() eq get_hello(),'get_string() equals get_hello()');
     12 
     13 sub get_number{
     14     23;
     15 }
     16 
     17 sub get_string{
     18     'hello world!'
     19 }
     20 
     21 sub get_hello{
     22     'hello world!'
     23 }

Ausgabe:

  ~/entwicklung 234> perl test_foo.pl 
  1..5
  ok 1 - erfolgreicher Test
  not ok 2 - nicht erfolgreicher Test
  #   Failed test 'nicht erfolgreicher Test'
  #   in test_foo.pl at line 8.
  ok 3 - 1 gleich 1
  ok 4 - get_number() liefert 23
  ok 5 - get_string() equals get_hello()
  # Looks like you failed 1 test of 5.

Test::More

Test::More ist so ziemlich das wichtigste Modul bei Tests. Es bietet einige Funktionen, die Tests erleichtern. Test::More erspart umständliche Aufrufe der ok-Funktion wie es in Test::Simple notwendig ist. Die ok-Funktion existiert zwar weiterhin, aber in den meisten Fällen ist eine andere Funktion besser.

Wichtig - wie bei Test::Simple - ist es, einen Plan festzulegen. Über den Plan teilt man Test::More mit, wie viele Tests gemacht werden sollen. Das ist ein Test in sich, da der Tester eine Meldung bekommt, wenn in dem Testskript mehr oder weniger Tests als angegeben durchgeführt wurden. Das kann darauf hindeuten, dass einige Tests vergessen wurden oder dass mehr Tests als nötig gemacht wurden.

Bei jedem Test, der geschrieben wird, muss also der Plan angepasst werden.

In den nachfolgenden Abschnitten werden einige Funktionen von Test::More besprochen.

Bei allen Tests, die bei Test::More gemacht werden, testen das folgende Modul:

   1 package FooBar;
   2 
   3 sub return_42{
   4     return 42;
   5 }
   6 
   7 sub echo{
   8     my ($echo) = @_;
   9     return $echo;
     10 }
     11
     12 sub random{
     13     my $text = 'Dies ist die Zufallszahl ' . rand($$);
     14     return $text;
     15 }
     16
     17 sub lower_case{
     18     my ($echo) = @_;
     19     $echo = lc $echo;
     20     return $echo;
     21 }
     22 
     23 sub get_title{
     24     my ($html) = @_;
     25     my ($title) = $html =~ m!<title>(.*?)</title>!;
     26     return $title;
     27 }
     28 
     29 sub todo{
     30 }
     31
     32 1;

Es ist natürlich möglich, die ok-Funktion zu verwenden, wie sie aus Test::Simple bekannt ist. In den meisten Fällen soll aber vermutlich etwas verglichen werden; entweder zwei Strings oder zwei Zahlen. Die erste Methode, die das Leben einfacher macht, ist cmp_ok. Diese Funktion benötigt drei Parameter plus den optionalen Test-Namen. Noch einfacher ist es allerdings mit der is-Funktion. Diese Funktion erkennt automatisch, ob Zahlen oder Strings verglichen werden sollen und macht den nötigen Abgleich.

Die drei folgenden Tests sind also äquivalent:

  1 #!/usr/bin/perl
  2
  3 use Test::More tests => 3;
  4 use FooBar;
  5
  6 my $number = 42;
  7 ok(FooBar::return_42() == 42);         # ok
  8 cmp_ok(FooBar::return_42(), '==', 42); # ok
  9 is(FooBar::return_42(),42);            # ok

Genauso wie:

  1 #!/usr/bin/perl
  2
  3 use Test::More tests => 3;
  4 use FooBar;
  5 
  6 my $string = 'Test';
  7 ok(FooBar::echo($string) eq $string);         # ok
  8 cmp_ok(FooBar::echo($string), 'eq', $string); # ok
  9 is(FooBar::echo($string),$string);            # ok

Für die Funktion is gibt es auch noch das Gegenteil und heißt sinnigerweise isnt. Damit können Vergleiche auf Ungleichheit gemacht werden:

  1 my $string = 'Test';
  2 isnt(FooBar::echo($string),'test'); # ok
  3 is(FooBar::echo($string),'test');   # not ok

Die eben genannten Funktionen prüfen auf Gleichheit. In einigen Fällen ist es aber so, dass man nicht genau weiß, wie etwas zurückgeliefert wird oder der Zufallszahlengenerator ist mit beteiligt - wie bei

  1 sub random{
  2     my $text = 'Dies ist die Zufallszahl ' . rand($$);
  3     return $text;
  4 }

Es ist aber ein Teil des Rückgabewerts bekannt. Im normalen Programm würde man gleich mit Regulären Ausdrücken anfangen. Auch Test::More bietet Funktionen, die mit Regulären Ausdrücken umgehen können: like und das Gegenteil dazu unlike.

Damit kann man auch Funktionen wie das oben beschriebene random testen:

   1 #!/usr/bin/perl
   2
   3 use Test::More tests => 3;
   4 use FooBar;
   5
   6 my $test     = 'Dies ist die Zufallszahl ';
   7 my $test_zwo = 'ein anderer Test ';
   8
   9 like(FooBar::random(),qr/$test/);       # ok
     10 unlike(FooBar::random(),qr/$test/);     # not ok
     11
     12 like(FooBar::random(),qr/$test_zwo/);   # not ok
     13 unlike(FooBar::random(),qr/$test_zwo/); # ok

Bisher wurden nur einfache Tests gemacht: Strings und Zahlen verglichen. In Perl gibt es aber noch andere Datentypen: Arrays und Hashes. Auch die sollen verglichen werden wenn sie der Rückgabewert einer Funktion sind.

Ein einfacher Vergleich wie dieser:

  1 my @array_eins = qw(1 2 3);
  2 my @array_zwo  = qw(1 2 3);
  3 is(\@array_eins,\@array_zwo);

geht schief.

  not ok 1
  #   Failed test in test_foo.pl at line 9.
  #          got: 'ARRAY(0x209624)'
  #     expected: 'ARRAY(0x164e74)'

Da muss also etwas anderes her. Test::More hat auch hier die entsprechende Funktion: is_deeply. Diese Funktion kann aber nur einfache Hashes beziehungsweise Arrays vergleichen. Für komplexe Datenstrukturen sind die Module Test::Differences und Test::Deep geeignet. Aber für Arrays und Hashes ist die is_deeply-Funktion von Test::More sehr gut geeignet:

  1 #!/usr/bin/perl
  2
  3 use Test::More tests => 2;
  4
  5 my @array_eins = qw(1 2 3);
  6 my @array_zwo  = qw(1 2 3);
  7 my @array_drei = qw(1 2 4);
  8 is_deeply(\@array_eins,\@array_zwo);
  9 is_deeply(\@array_eins,\@array_drei);

Ergibt folgende Ausgabe:

  ~/entwicklung 127> perl test_foo.pl 
  1..2
  ok 1
  not ok 2
  #   Failed test in test_foo.pl at line 13.
  #     Structures begin differing at:
  #          $got->[2] = '3'
  #     $expected->[2] = '4'
  # Looks like you failed 1 test of 2.

Es wird also auch gut aufgezeigt, an welcher Stelle etwas schief gelaufen ist.

An der Testausgabe sieht man, dass es auch Zusatzinformationen zu einem Test gibt. In diesem Fall wird angegeben, welche Elemente der Arrays ungleich sind. Solche zusätzlichen Ausgaben - die von Test::Harness übrigens ignoriert werden - können auch selbst ausgegeben werden. Dafür gibt es die Funktion diag:

  1 #!/usr/bin/perl
  2
  3 use Test::More tests => 1;
  4 
  5 diag('Diagnosemeldung: Test1');
  6 is(42,42);

Und die Ausgabe:

  ~/entwicklung 128> perl test_foo.pl 
  1..1
  # Diagnosemeldung: Test1
  ok 1

Für die Überprüfung, ob alle gewünschten Funktionen in einem Modul implementiert sind, gibt es die Funktion can_ok. Die Funktion akzeptiert sowohl ein Objekt als auch ein Modulname für den Test:

   1 #!/usr/bin/perl
   2 
   3 use strict;
   4 use warnings;
   5 use Test::More tests => 1;
   6 use FooBar;
   7
   8 my @methods = qw(echo return_42
   9                  lower_case random
     10                  get_title todo);
     11 
     12 can_ok('FooBar',@methods);

Da alle diese Methoden in dem Modul implementiert sind, bekommt erscheint diese Ausgabe:

  ~/entwicklung 129> perl test_foo.pl 
  1..1
  ok 1 - FooBar->can(...)

Für Objektorientierte Programmierung gibt es noch die Funktion isa_ok, die ein Objekt überprüft, ob es zu einer gegebenen Klasse gehört:

  1 #!/usr/bin/perl
  2 
  3 use Test::More tests => 1;
  4 use CGI;
  5 
  6 my $cgi = CGI->new();
  7 isa_ok($cgi,'CGI');

Da $cgi ein Objekt con CGI ist, erhält man folgende Ausgabe:

  ~/entwicklung 130> perl test_foo.pl 
  1..1
  ok 1 - The object isa CGI

Soll das Laden von Modulen getestet werden, stehen zwei Funktionen aus Test::More zur Verfügung: use_ok und require_ok. Die Namen sind dabei Programm: use_ok bindet ein Modul über use ein und das require_ok benutzt das require.

Mit folgendem Skript wird getestet ob zwei bestimmte Module installiert sind:

  1 #!/usr/bin/perl
  2 
  3 use strict;
  4 use warnings;
  5 use Test::More tests => 2;
  6
  7 use_ok('CGI');
  8 use_ok('NonExistentModule');

Da das zweite Modul nicht installiert ist, erscheint folgende Ausgabe:

  ~/entwicklung 154> perl test_foo.pl 
  1..2
  ok 1 - use CGI;
  not ok 2 - use NonExistentModule;
  #   Failed test 'use NonExistentModule;'
  #   in test_foo.pl at line 8.
  #     Tried to use 'NonExistentModule'.
  #     Error:  Can't locate NonExistentModule.pm 
    in @INC (@INC contains: ... .) at (eval 4) line 2.
  # BEGIN failed--compilation aborted at test_foo.pl line 8.
  # Looks like you failed 1 test of 2.

Die letzten beiden Punkte von Test::More sind der SKIP- und der TODO-Block. Mit dem SKIP-Block kann man einen Teil des Codes auslassen wenn eine bestimmte Bedingung erfüllt ist. Dies ist sehr nützlich, wenn für den Test eine Internetverbindung benötigt wird, bei einer nicht vorhandenen Internetverbindung nicht alle Tests fehlschlagen sollen. Sonst begibt man sich auf Fehlersuche und dabei lag es nur an der fehlenden Verbindung.

Ein weiterer - noch häufigerer - Anwendungsfall ist das Abfragen von Modulen. Wenn für Tests bestimmte Module benötigt werden, die auf dem Rechner vielleicht nicht installiert sind, macht es keinen Sinn, den Test weiter auszuführen.

Die folgenden zwei SKIP-Blöcke sollen dies demonstrieren:

   1 #!/usr/bin/perl
   2
   3 use strict;
   4 use warnings;
   5 use Test::More tests => 2;
   6 use LWP::Simple;
   7 
   8 SKIP:{
   9     eval "use NonExistentMod";
     10     skip "NonExistentMod not installed",1 if $@;
     11     
     12     NonExistentMod::subroutine();
     13 }
     14 
     15 SKIP:{
     16     my $content = get('http://www.1.de/');
     17     skip "Keine Verbindung",1 unless $content;
     18     
     19     require FooBar;
     20     is(FooBar::get_title($content),'Test');
     21 }

Da beides nicht funktioniert, wird folgende Meldung ausgegeben:

  ~/entwicklung 161> perl test_foo.pl 
  1..2
  ok 1 # skip NonExistentMod not installed
  ok 2 # skip Keine Verbindung

Mit dem TODO-Block kann angegeben werden, welche Tests fehlschlagen werden, weil die Funktionalität noch nicht implementiert ist. In dem Beispielmodul soll die Funktion todo in Zukunft mal den Satz "Hallo Welt!" zurückliefern. Der Funktionsrahmen ist zwar schon aufgeschrieben, die Funktion ist aber noch nicht mit Leben gefüllt.

So könnte also ein Test aussehen:

   1 #!/usr/bin/perl
   2
   3 use strict;
   4 use warnings;
   5 use Test::More tests => 1;
   6 use FooBar;
   7 
   8 TODO:{
   9     local $TODO = 'not yet implemented';
     10     is(FooBar::todo(),'Hallo Welt!','teste todo()');
     11 }

Die Testausgabe sieht dann so aus:

  ~/entwicklung 243> perl test_foo.pl 
  1..1
  not ok 1 - teste todo() # TODO not yet implemented
  #   Failed (TODO) test 'teste todo()'
  #   in test_foo.pl at line 10.
  #          got: undef
  #     expected: 'Hallo Welt!'

Wenn eine Testsuite mit Test::Harness gestartet wird, werden diese Tests im TODO-Block nicht als fehlgeschlagen gewertet.

Test::Exception

Mit Test::Exception können Module auf Warnungen und Fehler hin überprüft werden. Damit kann zum Beispiel überprüft werden, ob das Modul tatsächlich abbricht wenn eine nicht-existente Datei geöffnet werden soll.

Das Modul stellt die folgenden vier Methoden zur Verfügung.

• dies_ok
• throws_ok
• lives_ok
• lives_and

Mit dies_ok überprüft man, ob eine Funktion wie gewünscht abbricht. Programme liefern häufig falsche Ergebnisse wenn bei bestimmten Ereignissen nicht abgebrochen wird. Deshalb sollte ein Programm mit wissentlich falschen Daten gefüttert werden, um zu überprüfen, ob das Programm richtig darauf reagiert.

throws_ok überprüft auch, ob die Fehlermeldung durch einen bestimmten Regulären Ausdruck gematcht wird. Dies ist sinnvoll, wenn nicht nur überprüft werden soll, ob das Programm abbricht, sondern auch ob der ``richtige'' Fehler ausgegeben wird.

Eine Methode, die auf jeden Fall durchläuft, kann mit lives_ok getestet werden. Hierbei ist es völlig egal, welchen Rückgabewert die Methode hat. Nicht egal ist dies wiederum bei lives_and. Hier wird noch ein zusätzlicher Test auf den Rückgabewert gemacht.

Dieses Modul soll getestet werden:

   1 package FooBar;
   2 
   3 sub dies{
   4     open my $fh,'<','/dies/ist/ein/test.upc' or die $!;
   5     close $fh;
   6 }
   7 
   8 sub throws{
   9     my ($nenner) = @_;
     10     my $zahl = 19 / $nenner;
     11 }
     12 
     13 sub lives{
     14     1;
     15 }
     16 
     17 sub lives_42{
     18     42;
     19 }
     20 
     21 1;

Folgendes Testskript benutzt die vier Methoden von Test::Exception um den Einsatz des Moduls zu verdeutlichen:

   1 #!/usr/bin/perl
   2
   3 use strict;
   4 use warnings;
   5 use Test::More tests => 4;
   6 use Test::Exception;
   7 use FooBar;
   8 
   9 dies_ok   {FooBar::dies()           } 
     10               'died as expected';
     11 throws_ok {FooBar::throws(0)        } 
     12               qr/division by zero/i, 
     13               'Division by 0 not allowed';
     14 lives_ok  {FooBar::lives()          }
     15               'it does not matter what lives() returns';
     16 lives_and {is FooBar::lives_42(), 42} 
     17               'lives_42 returns 42';

Die Ausgabe des Tests sieht wie folgt aus:

  ~/entwicklung 79> perl test_foo.pl 
  1..4
  ok 1 - died as expected
  ok 2 - Division by 0 not allowed
  ok 3 - it does not matter what lives() returns
  ok 4 - lives_42 returns 42

Test::TestCoverage

Es wurde von mehreren Personen angemerkt, dass Test::TestCoverage sehr dem Modul Devel::Cover ähnelt. Es gibt Ähnlichkeiten im Sinn und Zweck der Module, aber Test::TestCoverage verfolgt eine etwas andere Strategie.

Test::Coverage vs Devel::Cover

Mit Devel::Cover kann überprüft werden, wie häufig bestimmt Code-Stücke aufgerufen wurde. So kann man feststellen, ob unnützer Code geschrieben wurde. Test::TestCoverage interessiert sich nicht dafür, wie oft ein Code-Stück aufgerufen wurde und erzeugt auch nicht den Overhead an Statistiken. Test::TestCoverage interessiert sich nur dafür, ob auch tatsächlich alle ``public''-Methoden im Testskript aufgerufen wurden.

Nachfolgend werden die Funktionen von Test::TestCoverage erläutert.

• test_coverage
• ok_test_coverage
• reset_test_coverage
• reset_all_test_coverage

Mit test_coverage wird ein Modul zur Überprüfung ``angemeldet''. Wenn das Modul noch nicht geladen ist, dann wird es automatisch geladen. Dies ist auch notwendig, damit Test::TestCoverage die Subroutinen des Moduls herausfindet.

Der eigentliche Test ist ok_test_coverage. Standardmäßig wird dabei das zuletzt angemeldete Modul überprüft. Soll ein anderes Modul getestet werden, muss der Name als Parameter übergeben werden.

Wurden mehrere Module ``angemeldet'', kann man die Tests auch vereinfachen und über all_test_coverage_ok alle Module auf einmal testen.

Als Beispielmodul wird folgendes Modul genommen:

  1 package FooBar;
  2
  3 sub new{ bless {},shift }
  4
  5 sub echo{
  6     my ($self,$echo) = @_;
  7     print $echo,"\n";
  8 }
  9 1;

Dieses Modul soll getestet werden und bei dem Test soll darauf geachtet werden, dass alle public-Methode verwendet werden (hier: new und echo). Das Testskript sieht dann wie folgt aus:

   1 #!/usr/bin/perl
   2
   3 use strict;
   4 use warnings;
   5 use Test::More tests=>1;
   6 use Test::TestCoverage;
   7
   8 test_coverage('FooBar');
   9 
     10 my $foo = FooBar->new();
     11 
     12 ok_test_coverage();

Wenn der Test so läuft, erhält man folgende Ausgabe:

  ~/entwicklung 67> perl test_foo.pl 
  1..1
  not ok 1 - Test test-coverage echo  are missing
  #   Failed test 'Test test-coverage echo  are missing'
  #   in test_foo.pl at line 12.
  #          got: 0
  #     expected: 1
  # Looks like you failed 1 test of 1.

Damit wird angezeigt, dass die Methode echo nicht aufgerufen wird. Fügt man einen Aufruf der Methode ein, so sieht das Testskript folgendermaßen aus:

   1 #!/usr/bin/perl
   2
   3 use strict;
   4 use warnings;
   5 use Test::More tests=>1;
   6 use Test::TestCoverage;
   7
   8 test_coverage('FooBar');
   9 
     10 my $foo = FooBar->new();
     11 $foo->echo('Hallo Welt');
     12 
     13 ok_test_coverage();

Jetzt läuft der Test fehlerfrei durch:

  ~/entwicklung 69> perl test_foo.pl 
  1..1
  Hallo Welt
  ok 1 - Test test-coverage

Das Modul hat noch einige Schwächen, da zum Beispiel exportierte Methoden noch nicht überprüft werden können. Da ist Devel::Cover schon einiges weiter.

Test::CheckManifest

Dieses Modul ist eigentlich kein Test-Modul um Funktionalität zu sichern, sondern unterstützt den Programmierer bei der Einhaltung von CPAN-Konformität. In der MANIFEST-Datei sind alle Dateien aufgeführt, die zu einer Distribution gehören - zumindest sollte es so sein.

Ob dies auch tatsächlich der Fall ist, kann sehr einfach mit Test::CheckManifest überprüft werden. Ein

  1 use Test::More tests => 1;
  2 
  3 SKIP:{
  4     eval "use Test::CheckManifest 1.0";
  5     skript "Test::CheckManifest 1.0 required",1 if $@;
  6     
  7     ok_manifest();
  8 }

ist ausreichend.

Die Methode ok_manifest ist die einzige Methode, die es in dem Modul gibt.

Der Methode kann aber in einer Hashreferenz ein Filter und Informationen über Verzeichnisse mitgegeben werden, die aus dem Test ausgeschlossen werden sollen.

So kann mit

  ok_manifest({filter => [qr/\.svn/]});

ein Filter übergeben werden, der alle Dateien von dem Test ausschließt, die ein .svn im Namen (oder im Pfadnamen) haben.

Mit

  ok_manifest({exclude => ['/.svn']});

werden alle Dateien aus dem .svn-Ordner ausgeschlossen.

-- ReneeBaecker - 15 Apr 2009