[Vienna-pm] Naechstes Meeting: 7.4.

[Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]

> why is automated testing important?
> Or why to write tests?

Mein [Pitch](http://de.wikipedia.org/wiki/Elevator_Pitch): Du hast Software 
geschrieben und sie manuell geprüft. Daher weißt du, dass sie wie gewünscht 
funktioniert. Jetzt veränderst du die Software. Woher weißt du, dass sie immer 
noch so funktioniert wie zuvor? Du müsstest sie komplett neu prüfen. (Leider 
reicht es nicht, nur die Stelle zu testen, wo die Veränderung war. In einigen 
Fällen ist mehr betroffen, als man annimmt.) Daher automatisierte Tests, denn 
so wird Software *schnell*, *zuverlässig* und *eindeutig* geprüft.

Automatisierte Tests sind *Arbeitsersparnis*. Wer meint, Zeit zu sparen, indem 
er die Tests weglässt, der irrt sich, denn Programmierer verbringen 80% ihrer 
Zeit mit *Wartung* von Software.

Alternativ kann man auch einfach das erste Kapitel von Büchern über Testing 
vorlesen, oder das C2-Wiki. :->

Wenn der Gesprächspartner noch nicht eingeschlafen ist, kann man dann in 
Themen abschweifen, die durch automatisierte Tests erst ermöglicht werden: 
Smoking/verteilte QA (CPAN Testers), TAP-Ökosystem (Smolder), Modelle der 
Entwicklung (XP/Agile).

> Is there any best practice for splitting white box and black box tests
> in a distribution t/?
Das habe ich noch nicht als eindeutige Richtlinie in der freien Wildbahn 
wahrgenommen.

> Different files?
Ja, so würde ich es machen. Wenn sich die Implementation der Software ändert 
und daher das Interface/Blackbox stabil bleibt, ist es einfacher, die 
Glassbox-Tests zu überarbeiten, wenn sie komplett getrennt vorliegen.

> Any good article about the structure of a test files?
Meistens will man keine Struktur, oder anders gesagt reicht unstrukturierte 
Stapelverarbeitung von oben nach unten aus. (Einzelne zusammengehörenden Tests 
soll man aber schon in nackten Blocks `{}` oder neuerdings [Subtests]
(http://p3rl.org/Test::More#subtest) kapseln.)

Der Grund dafür: wenn ein Test fehlschlägt, ist entweder hoffentlich die 
getestete Software falsch oder der Test ist falsch. Wenn man dann den Test 
anschaut, soll man sofort auf einen Blick erkennen, ob der Test an sich so in 
Ordnung ist. Je einfacher ein Test ist, desto leichter ist das zu erkennen.

Manchmal hat man aber echt komplexe Software mit viel Vorbereitung, ehe man 
zum eigentlichen Testen kommt. Da helfen:

<http://rjbs.manxome.org/rubric/entry/1858> 
<http://p3rl.org/Test::Routine::Manual::Demo>
<http://www.slideshare.net/Ovid/testing-with-testclass> 
<http://p3rl.org/Test::Class::Most>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.pm.org/pipermail/vienna-pm/attachments/20110411/b5bc1892/attachment.bin>