[björn]

Hi,
habe mir letztens das Buch gekauft:
http://forum.developers-guide.net/sh...ad.php?p=35717
und nun steht in Kapitel 6 was über Unit Tests.

Bei 'einfacheren' Funktionen wie z.B.

PHP-Code:

function splitMail($mail)
{
  return explode('@', $mail);
} 


ist es sicher nicht schwer, einen UnitTest zu programmieren. Nur frage
ich mich, wie man es bei Funktionen machen möchte, die eventuell bei
bestimmten Parametern einfach nicht das machen, was sie sollen.
Oder wie macht man es z.B. bei Funktionen, die ein Watermark
in ein anderes Bild einfügen oder ein Thumbail eines anderen Bildes erstellen.

Wie will man das gescheit testen?

Danke!!

guis kann man mit unit tests so gut wie gar nicht testen. dafür gibt's andere test-methoden. und vollständig kannst du eh auch nicht testen, denn die anzahl an möglichen pfaden durch dein programm wächst super-exponentiell. siehe auch path enumeration problem.

by the way: zum unit testing gehört _nicht_ nur das automatisierte testen. ein unit test kann durchaus sein, dass man diverse aktionen im interface ausführt und schriftlich die ergebnisse festhält.

bei bildern kann man z.b. auch den trick machen, ein referenz-bild zu hinterlegen (d.h. das bild mit dem gewünschten ergebnis), und das generierte bild (nach irgendwelchen kriterien) mit diesem referenz-bild zu vergleichen. das kann man z.b. auch mit toleranzintervallen machen, und damit das ganze sogar automatisieren. meist ist aber das test-setup bereits so aufwändig, dass es sich nicht lohnt, sowas zu machen. also bleibt das ungetestet, bzw. wird einmal händisch getestet, und danach wird der code eingefroren, d.h. nicht mehr verändert.

das axiom lautet: wie kann ich mit möglichst wenig aufwand möglichst viele fehler aufdecken, d.h. als testerIn erfolgreich sein?
das führt im prinzip dazu, dass man möglichst viel automatisiert, aber nur das, was mit akzeptablem aufwand auch automatisierbar ist. alles andere wird von menschenhand getestet.

[björn]

Danke für die Antwort.
Genau, teilweise ist es echt aufwändiger, die Unittests zu schreiben, als den zu testenden Code selbst

Zitat von björn

Danke für die Antwort.
Genau, teilweise ist es echt aufwändiger, die Unittests zu schreiben, als den zu testenden Code selbst

richtig. man darf aber daraus nicht den schluss ziehen, dass unit tests nur aufwändig sind. lieber ein test zu viel als einer zu wenig, außerdem rentieren sich die automatisierten tests eh erst nach mehr als einem halben jahr, nämlich dann, wenn änderungen am bestehenden code gemacht werden müssen.

grüße
axo

[MrNiceGuy]

Also ich teste meine Scripte immer nach jedem mittelgroßen Schritt einmal komplett, damit ich weiß, dass die neue Funktion die integriert wurde auch so läuft, wie sie soll. Die fiesesten Fehler findet man eh erst in der Live-Umgebung, da man als Programmierer garnicht so doof denken kann, wie manche User sind. Oder ergeht es nur mir so, dass ganz banale Sachen, die für einen selber selbstverständlich sind, dass man davon die Finger lässt, zu Fehlern führen können und von irgendwelchen DAUs gefunden werden? Also ab und zu?!

[Ben]

Du bist nicht allein!

äh... nö. userIn ist nie schuld. programmiererIn ist immer* schuld.
zum testen gehört auch die evaluation, ob das user-interface / die website etc. so benutzerInnenfreundlich ist, dass er/sie damit auch gut zurechtkommt.
hat man diesen punkt beim prototyping vernachlässigt und hat man's dann auch noch verpasst, beim integration testing diesen aspekt ordentlich zu evaluieren, und beliefert man dann den kunden mit einem unverständlichen, schwer oder missverständlich zu bedienenden produkt, kann nicht der kunde schuld sein.
nicht der kunde ist doof - der kunde ist kein techniker, der von der materie ahnung haben muss. er muss das ganze intuitiv bedienen können, d.h. die software muss auch in maßen zu seinem vokabular passen, angemessen große schriften und angemessen kontrastreiche farben haben, und wenn es mal nicht intuitiv geht, muss hilfe-doku, ein rückgängig-button, ein wizard, eine hotline etc. da sein, um ihn dabei zu unterstützen.

beispiel heute:
ich sehe in der post einer mitarbeiterin zu, wie sie einem anderen kunden kohle auszahlt. der will natürlich seine quittung haben. mitarbeiterin kann nicht ausdrucken, holt kollegen zur hilfe. der sagt 'geht nicht, dass du drucken willst hättest du vor der auszahlung eingeben müssen'...
was ist passiert?
das menü im buchungsprogramm der post ist so schlecht gemacht, dass man nur in einem bestimmten fenster die quittung ausdrucken kann, und zwar muss man das machen, bevor man die auszahlung durchführt. danach kommt man nicht mehr zurück, und kann somit dem kunden keine quittung mehr geben.
geil, oder? und hier soll der kunde schuld sein? ist jetzt der kunde daran schuld, dass er/sie nicht wie der programmierer fünf minuten vorher ans drucken gedacht hat?

sowas passiert schon immer wieder, aber aus jedem fehler muss man lernen, die fehler beheben und die daraus gezogenen schlüsse dann ins eigene qualitätsmanagement übernehmen, damit sowas nicht mehr vorkommt. vor allem lässt sich sowas relativ gut automatisieren, indem man sich darum kümmert, diese usability-aspekte implizit von einem framework ausführen zu lassen... so wie z.b. html-quickform-controller, das automatisch die vor-zurück-jump-navigation für mehrseitige menüs hat. nur mal so als beispiel.


grüße
axo

* so gut wie. gegen die leute, die sich über den abgebrochenen kaffee-tassen-halter am computer beschweren, kann man nichts machen. gehen wir einfach mal von einem mäßig gebildeten kunden aus, der weiß wie man tastatur und maus benutzt, wie man etwas klickt undsoweiter.

[Ben]

Stimme ich dir voll und ganz zu, aber wir haben auch nicht gesagt (zumindest ich nicht), dass wir keine Schuld am Fehler tragen. Kloar .. wir haben es programmiert. Wir haben nur gesagt, dass wir den Fehler gemacht haben uns nicht so "dumm" wie den DAU vor die Anwendung gesetzt zu haben.

ist ja technisch gar nicht möglich, sonst hätten wir es ja nicht geschafft, die anwendung zu schreiben...
ne, is klar. passiert mir auch immer wieder, dass ein kunde irgendwas anders klickt als ich und plötzlich alles abschmiert. aber es passiert immer seltener, je länger man im geschäft ist ...

gute nacht
axo

[MrNiceGuy]

@axo: Ich wollte damit die Schuld keineswegs auf den User lenken und auch nicht behaupten, dass alle User doof / DAUs sind, aber Fakt ist nunmal, dass viele Fehler erst auftreten, wenn sich User ohne Programmierkenntnisse an den Programmen vergreifen, da man selber als Programmierer meistens garnicht so quer denken kann und an bestimmte Dinge nicht gedacht hat sie in den Code mit einzubauen, weil man von seinem logischen Verständnis her nie auf die Idee kommen würde, es auszuprobieren.

Natürlich kann man das durch eine vernünftige Planung alles versuchen auszugleichen, aber meiner Meinung nach gibt es die perfekte Planung nicht. Jeder, egal wer, übersieht hier und da eine Kleinigkeit, die später zu einem Fehler führen kann.

[björn]

Jop sehe ich genauso. Ich teste meine Programme auch immer nochmals per Hand und gehe auf Fehlersuche!!

[Jojo]

Also mithilfe meiner bevorzugten Beta-Testerin (Mutter) habe ich bis jetzt jeden (groben) Fehler ermitteln können.
Sowohl die Programmier-, als auch die Logikfehler in der GUI
Obwohl ich langsam das Gefühl bekomme, dass meine Mutter mittlerweile nicht mehr unbedarft genug ist.
Vielleicht sollte ich mal meine Oma fragen ^^

[Ben]

Bin gerade auf diesen Artikel hier gestoßen:
http://blog.thinkphp.de/archives/133...-Selenium.html

Ich poste den Link mal hier, weil es irgendwie recht gut in das Thema passt (finde ich zumindest).

Grüße, Ben.

[Ben]

Und noch ein Artikel:
http://www-128.ibm.com/developerwork...y/os-php-unit/