Re: Test::Harness & Co. und "die"

Florian Weimer wrote:

> Ich habe eine Hilfsfunktion, sagen wir test_foo, die die zu testenden
> Funktionalität aufruft und einen Wert zurückgibt. Verwendet wird das
> wie folgt:
>
> like(test_foo("bar"), qr/baz/, $test_name);
>
> So weit so gut. Nun kann es passieren, daß test_foo selbst einen
> Fehler detektiert und "die" aufruft. Das wird vom Test::*-Framework
> allerdings nicht so recht behandelt (es wird nicht eindeutig als
> Fehler erkannt, ähnlich wie wenn der Perl-Prozeß durch ein Signal
> stirbt).
>
> Wie kann ich das vernünftig lösen?

Besorg Dir Test::Exception.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Test::Harness & Co. und "die"

Ich habe eine Hilfsfunktion, sagen wir test_foo, die die zu testenden
Funktionalität aufruft und einen Wert zurückgibt. Verwendet wird das
wie folgt:

like(test_foo("bar"), qr/baz/, $test_name);

So weit so gut. Nun kann es passieren, daß test_foo selbst einen
Fehler detektiert und "die" aufruft. Das wird vom Test::*-Framework
allerdings nicht so recht behandelt (es wird nicht eindeutig als
Fehler erkannt, ähnlich wie wenn der Perl-Prozeß durch ein Signal
stirbt).

Wie kann ich das vernünftig lösen? Die Rückgabe eines Dummy-Wertes
möchte ich vermeiden. Die Lokalisierung des fehlerhaften Testcases hat
nicht oberste Priorität, es reicht, wenn hinreichend deutlich wird,
daß etwas oberfaul ist.

Re: Test::Harness & Co. und "die"

* Frank Seitz:

> Florian Weimer wrote:
>
>> Ich habe eine Hilfsfunktion, sagen wir test_foo, die die zu testenden
>> Funktionalität aufruft und einen Wert zurückgibt. Verwendet wird das
>> wie folgt:
>>
>> like(test_foo("bar"), qr/baz/, $test_name);
>>
>> So weit so gut. Nun kann es passieren, daß test_foo selbst einen
>> Fehler detektiert und "die" aufruft. Das wird vom Test::*-Framework
>> allerdings nicht so recht behandelt (es wird nicht eindeutig als
>> Fehler erkannt, ähnlich wie wenn der Perl-Prozeß durch ein Signal
>> stirbt).
>>
>> Wie kann ich das vernünftig lösen?
>
> Besorg Dir Test::Exception.

Dann muß ich alle Testcases umschreiben. Die zusätzliche Abhängigkeit
ist auch nicht gerade erfreulich.

Außerdem ist mir ziemlich egal, welche Exception geworfen wird. Mir
geht es primär um den Fall, daß der Test-Framework selbst abraucht
(die getestete Funktionalität ist eh in einem getrennten Programm, das
von den Testcases aufgerufen wird).

Möglicherweise sollte ich ein like_foo definieren, das like und
test_foo kombiniert, aber das krank ebenfalls am Umschreibeproblem.
Was mir spontan noch so einfällt wäre, test_foo dahingehend zu ändern,
daß test_foo undef im Fehlerfall zurückgibt, vorher aber in einer
globalen Variable den Fehler aufzeichnen. Am Ende jedes Testcases, der
test_foo verwendet, muß dann ein zusätzlicher test_foo ok aufgerufen
werden, der prüft, ob irgendwelche aufgezeichneten Fehler vorliegen.
Nicht schön, aber könnte funktionieren.

Lieber wäre mir jedoch, daß ich einfach dem Test::-Framework
signalisieren könnte "der gegenwärtige Plan hat versagt, egal was
kommt".

Re: Test::Harness & Co. und "die"

Florian Weimer wrote:
> * Frank Seitz:
>>
>>Besorg Dir Test::Exception.
>
> Dann muß ich alle Testcases umschreiben.

Nur die, in denen Exceptions auftreten. Aber das musst Du
sowieso, wenn Du es ordentlich machen willst.

> Die zusätzliche Abhängigkeit ist auch nicht gerade erfreulich.

Das stimmt.
Ansonsten hast Du noch die recht simple Option, den Aufruf
von test_foo() in ein eval() einzupacken und dann $@ oder den
Returnwert zu prüfen, à la

$r = eval { test_foo("bar") };
ok !$@;
like $r, qr/baz/;

> Lieber wäre mir jedoch, daß ich einfach dem Test::-Framework
> signalisieren könnte "der gegenwärtige Plan hat versagt, egal was
> kommt".

Klingt nach Gefrickel, aber vielleicht ist auch skip() was für Dich.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Test::Harness & Co. und "die"

Florian Weimer writes:

> * Frank Seitz:
>
> > Florian Weimer wrote:
> >
> >> Ich habe eine Hilfsfunktion, sagen wir test_foo, die die zu testenden
> >> Funktionalität aufruft und einen Wert zurückgibt. Verwendet wird das
> >> wie folgt:
> >>
> >> like(test_foo("bar"), qr/baz/, $test_name);
> >>
> >> So weit so gut. Nun kann es passieren, daß test_foo selbst einen
> >> Fehler detektiert und "die" aufruft. Das wird vom Test::*-Framework
> >> allerdings nicht so recht behandelt (es wird nicht eindeutig als
> >> Fehler erkannt, ähnlich wie wenn der Perl-Prozeß durch ein Signal
> >> stirbt).
> >>
> >> Wie kann ich das vernünftig lösen?
> >
> > Besorg Dir Test::Exception.
>
> Dann muß ich alle Testcases umschreiben. Die zusätzliche Abhängigkeit
> ist auch nicht gerade erfreulich.
>
> Außerdem ist mir ziemlich egal, welche Exception geworfen wird. Mir
> geht es primär um den Fall, daß der Test-Framework selbst abraucht
> (die getestete Funktionalität ist eh in einem getrennten Programm, das
> von den Testcases aufgerufen wird).
>
> Möglicherweise sollte ich ein like_foo definieren, das like und
> test_foo kombiniert, aber das krank ebenfalls am Umschreibeproblem.
> Was mir spontan noch so einfällt wäre, test_foo dahingehend zu ändern,
> daß test_foo undef im Fehlerfall zurückgibt, vorher aber in einer
> globalen Variable den Fehler aufzeichnen. Am Ende jedes Testcases, der
> test_foo verwendet, muß dann ein zusätzlicher test_foo ok aufgerufen
> werden, der prüft, ob irgendwelche aufgezeichneten Fehler vorliegen.
> Nicht schön, aber könnte funktionieren.
>
> Lieber wäre mir jedoch, daß ich einfach dem Test::-Framework
> signalisieren könnte "der gegenwärtige Plan hat versagt, egal was
> kommt".

Ist es ein erwarteter Fehler oder ein unerwarteter? Wenn ersteres,
dann musst du halt den Aufruf in eval { } einpacken und für alle
Ergebnisse vorbereitet sein:

my $ret = eval { test_foo("bar") };
ok($@ =~ /erwartete exception/ || ($@ eq "" && $ret =~ /baz/));

Wenn der Fehler unerwartet ist, dann solltest du lieber deinen Code
fixen :-)

Oder du schreibst einfach ein großes eval { } um den gesamten
Test-Code und arbeitest ohne plan.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de
BBBike - route planner for cyclists in Berlin
WWW version: http://www.bbbike.de
Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net

Re: Test::Harness & Co. und "die"

Slaven Rezic wrote:

> Ist es ein erwarteter Fehler oder ein unerwarteter? Wenn ersteres,
> dann musst du halt den Aufruf in eval { } einpacken und für alle
> Ergebnisse vorbereitet sein:
>
> my $ret = eval { test_foo("bar") };
> ok($@ =~ /erwartete exception/ || ($@ eq "" && $ret =~ /baz/));
>
> Wenn der Fehler unerwartet ist, dann solltest du lieber deinen Code
> fixen :-)

Volle Zustimmung. Allerdings widersprichst Du Dir aufgrund des ||
mit obigem Code ein wenig selbst.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Test::Harness & Co. und "die"

Frank Seitz writes:

> Slaven Rezic wrote:
>
> > Ist es ein erwarteter Fehler oder ein unerwarteter? Wenn ersteres,
> > dann musst du halt den Aufruf in eval { } einpacken und für alle
> > Ergebnisse vorbereitet sein:
> >
> > my $ret = eval { test_foo("bar") };
> > ok($@ =~ /erwartete exception/ || ($@ eq "" && $ret =~ /baz/));
> >
> > Wenn der Fehler unerwartet ist, dann solltest du lieber deinen Code
> > fixen :-)
>
> Volle Zustimmung. Allerdings widersprichst Du Dir aufgrund des ||
> mit obigem Code ein wenig selbst.
>

Tja, ich kenne leider die Motive des OP nicht, dann könnte ich
gezieltere Vorschläge machen...

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

sf-upload: make batch releases on SourceForge
http://sf-upload.sf.net

Re: Test::Harness & Co. und "die"

* Frank Seitz:

> $r = eval { test_foo("bar") };
> ok !$@;
> like $r, qr/baz/;

Oder gleich ($r, $@) in test_foo zurückgeben.

Ich bin aber inzwischen bei

like test_foo("bar"), qr/baz/;
# ...
foo ok;

gelandet, wobei "foo_ok" ein einzelner Test ist um zu sehen, ob einer
der vorangegangenen test_foo-Aufrufe fehlgeschlagen ist. Ein
__END__-Handler kann ggf. noch eine Warnung ausgeben, wenn foo_ok
nicht nach dem letzten test_foo aufgerufen wurde.

Re: Test::Harness & Co. und "die"

Florian Weimer wrote:
> * Frank Seitz:
>>
>> $r = eval { test_foo("bar") };
>> ok !$@;
>> like $r, qr/baz/;
>
> Oder gleich ($r, $@) in test_foo zurückgeben.
>
> Ich bin aber inzwischen bei
>
> like test_foo("bar"), qr/baz/;
>
> # ...
> foo ok;
>
> gelandet, wobei "foo_ok" ein einzelner Test ist um zu sehen, ob einer
> der vorangegangenen test_foo-Aufrufe fehlgeschlagen ist.

Und woher weiß foo_ok das?

> Ein
> __END__-Handler kann ggf. noch eine Warnung ausgeben, wenn foo_ok
> nicht nach dem letzten test_foo aufgerufen wurde.

So lange das Test All Protocol (TAP) eingehalten wird, kann man
ja Beliebiges tun. Es ist aber - wie immer - sinnvoll,
die Dinge so einfach zu halten wie möglich.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: test

Bitte keine Multiposts oder Testpostings nach dclpm. Newsgroups sind
kein Chatroom, bei dem die Nachrichten sofort zu sehen sind. Für
Testposts gibt es eine Unmenge an Gruppen, die das Wort 'test' im Namen
tragen.

Danke,

Joergen

MOMO schrieb:
> test
>

Re: test

Guten Morgen Sorry,
Ich weiss dass MAnn sollte kein Post 2 Mal Schiken !

Den Problem ,dass nach absenden wurde mein NAchricht nicht auf die
HAuptseite gezeigt!

deswegen habe ich es noch mal Probiert!

ich bete Um Entschuldigung.

Grüß
OMAr

entschuldige!

Guten Morgen Sorry,
Ich weiss dass MAnn sollte kein Post 2 Mal Schiken !

Den Problem ,dass nach absenden wurde mein NAchricht nicht auf die
HAuptseite gezeigt!

deswegen habe ich es noch mal Probiert!

ich bete Um Entschuldigung.

Grüß
OMAr