Das deutsche Python-Forum

Ja, Mocking hatte ich mir nach einer von pokers Antworten schon angeschaut. Das Problem ist aber auch hier: Wenn man die Datenrückgabe eines Servers simulieren will, ist das sehr aufwendig. Wenn ich nichts simuliere, ist der Test nur sehr grob.
MfG
HWK

Das stimmt, aufwendig ist es. Es ist aber auch aufwendig, einen Fehler zu finden, der sich unbemerkt vor ein paar Tagen eingeschlichen hat. Insbesondere, wenn du gegen fremde Webservices programmierst, ist praktisch zu sehen, ob der Fehler in deinem Code liegt oder auf seiten des Webservice.

Unittests sind allgemein aufwendig, die Theorie ist halt, dass es noch aufwendiger ist, ständig nach Fehlern zu suchen und von Hand zu testen.

Ich sehe schon ein, dass Testing sinnvoll ist. Ich werde auch versuchen, für einfachere meiner Programmen mal eine unittest zu schreiben, um Erfahrungen damit zu sammeln und evtl. bei neuen Projekten von Anfang an Tests mitzuschreiben. Ich denke aber, was in diesem Thread ja auch schon angeklungen ist, dass man als Hobbyprogrammierer Kompromisse eingehen kann und muss. Zwei meiner am meisten verwendeten größeren Programme sind mit GUI und Netzwerk-/Internet-Anbindung. Hierfür unittests zu haben, wäre schon toll, da ich hier häufiger etwas anpassen möchte, ich mich wegen möglicher Fehler aber doch damit etwas zurückhalte. Für diese Programme, die jeweils um die 70 KB Quellcode enthalten, nachträglich Test zu schreiben, halte ich aber z.B. für mich als Einzelkämpfer schlicht für nicht praktikabel.
MfG
HWK

Just heute drüber gestolpert: http://pypi.python.org/pypi/MiniMock

Y0Gi hat geschrieben:Ich mache auch nur vereinzelt (und gewöhnlich nachträglich) Unittests, weil das bei Webanwendungen nicht so einfach ist

Jep, das stimmt. Allerdings bietet z.B. django dazu einige Handreichungen:
http://www.djangoproject.com/documentation/testing/
Genial finde ich den "test client" mit dem man Request konstruiert und dann den Response überprüfen kann... Eine sehr schöne Sache...

HWK hat geschrieben: Für mich sehe ich ein weiteres Problem: Meine größeren Programme, die ich häufig und lange verwende und somit auch öfter anpasse, arbeiten meistens mit einer GUI wie wxPython oder Tkinter. Dafür Tests zu schreiben ist aber wesentlich aufwendiger, evtl. sogar mehr als den Programmcode selbst zu schreiben.

Das ist klar und haben Tests auch ansich. Ein Test der 100% eine Applikation abdeckt ist immer umfangreicher als der zu testenden Code (Meiner Erfahrung nach). wxPython Widgets sind, wie im geposteten link vorgestellt, garnicht so kompliziert zu Testen. Das liegt auch mit daran das Python eine dynamische Sprach ist, es kein Private/Protected Mechanismus gibt und dadurch bedingt "extrem" einfach macht sowas zu testen Aber klar, es ist immer noch umfangreicher und schwieriger als CLI Programme zu Unit testen. Ob sich das für einen Hobby programmiere loht muss man von Fall zu Fall abwägen.

HWK hat geschrieben: Wahrscheinlich ist es hier effektiver, auf Tests zu verzichten und den Code dann anzupassen, wenn Fehler bei der Verwendung auftreten.

Ich denke IMO eher nicht. Es gab doch mal so ein Sprichwort das besagt das auf ein Bugfix 10 neue Bugs hinzukommen. Unit tests vermeiden das halt, weil man dadurch Änderungen verifizieren kann.

Zugegeben, ich mag die "Sicherheit" die mir ein Unit test bietet sehr. So kann ich entspant Änderungen machen und mit den Test gegenchecken ob ich nicht doch irgendwo ein Bug gebaut habe.

Y0Gi hat geschrieben: Ich mache auch nur vereinzelt (und gewöhnlich nachträglich) Unittests, weil das bei Webanwendungen nicht so einfach ist wie z.B. eben einer Library ohne Web-Interface oder GUI.

Ja, Webanwendungen sind echt ein Problem! Das ist ingrunde IMO auch einer der Bereiche wo man nicht mehr verhältnismäßig (=Zeit, Umfang) gut mit Mocking arbeiten kann. Da ist es "angebracht" sich gleich eine richtige Testumgebung mit Server, DB, etc einzurichten. Aber ob der Aufwand sich dann auch rechnet...? Gute frage...Was sagen die Pocoo Devs? Wie macht ihr das mit Pocoo? Wie sieht es mit MoinMoin aus? Irgendwie finde ich das da gerade irgendwie düster (Kommt mir vor als ob da nicht wirklich alles abgedeckt wird).

HWK hat geschrieben:Ich werde auch versuchen, für einfachere meiner Programmen mal eine unittest zu schreiben, um Erfahrungen damit zu sammeln und evtl. bei neuen Projekten von Anfang an Tests mitzuschreiben.

Das würde ich dir auch empfehlen. Wenn du dann auf den Geschmack gekommen bist, willst du nie wieder anders arbeiten

poker hat geschrieben:Es gab doch mal so ein Sprichwort das besagt das auf ein Bugfix 10 neue Bugs hinzukommen.

Das erinnert mich an die Fvwm-Manpage:

BUGS
As of fvwm version 2.4.0 there were exactly 71.8 unidentified bugs.
Since then 22.825 bugs have been fixed. Assuming that there are at
least 10 unidentified bugs for every identified one, that leaves us
with 71.8 - 22.825 + 10 * 22.825 = 277.225 unidentified bugs. If we
follow this to its logical conclusion we will have an infinite number
of unidentified bugs before the number of bugs can start to diminish,
at which point the program will be bug-free. Since this is a computer
program infinity = 3.4028e+38 if you do not insist on double-precision.
At the current rate of bug discovery we should expect to achieve this
point in 4.27e+27 years. I guess we better plan on passing this thing
on to our children...

Das einzige Problem an Unittests sind fehlerhafte Tests. Ich meine mich zu erinnern, daß Guido im Rahmen der Python3000-Entwicklung einige in CPython aufgefallen waren, die lediglich Bugs oder fragwürdige Implementationen der CPython-Implementierung festhielten. (Finde leider gerade die Verweise nicht mehr...)