Seite 1 von 1
Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Sonntag 17. Juni 2007, 16:13
von McEnroe
Ich habe gerade das unittest Modul für mich entdeckt. Ich finde den Ansatz des Unittesting toll. Deshalb habe ich mir gedacht, ein paar Test für meine Module und Anwendungen zu basteln. Das konkrete Modul soll Applikationen (bzw. ihre Quellen) aus SVN-Repositorys beziehen, configuriern (./configure; cmake) bauen und installieren. Dabei baut es auf eine Konfigurationsdatei auf aus der es URLs, Flags, Optionen usw. bezieht. Dabei sind viele Funktionen "void"-Funktionen (d.h. Funktionen ohne Rückgabewert wie zum Beispiel "doSvnUpdate()").
Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
Re: Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Sonntag 17. Juni 2007, 17:58
von lunar
McEnroe hat geschrieben:Dabei sind viele Funktionen "void"-Funktionen (d.h. Funktionen ohne Rückgabewert wie zum Beispiel "doSvnUpdate()").
die aber doch hoffentlich im Fehlerfall Ausnahmen auslösen, ansonsten kannst du ...
Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
... das nämlich nicht wirklich vernünftig testen.
Re: Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Sonntag 17. Juni 2007, 18:13
von McEnroe
lunar hat geschrieben:McEnroe hat geschrieben:Dabei sind viele Funktionen "void"-Funktionen (d.h. Funktionen ohne Rückgabewert wie zum Beispiel "doSvnUpdate()").
die aber doch hoffentlich im Fehlerfall Ausnahmen auslösen, ansonsten kannst du ...
Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
... das nämlich nicht wirklich vernünftig testen.
Nicht direkt. Sie returnen den Returncode der Anwendung die sie ausführen. Das könnte man noch testen. Das Problem ist eher, die Datenquelle. Ich kann nicht einfach ein SVN Repository zum Testen mitgeben.
Also: Was returnen die? -> Wie manage ich die Quelle, deren Daten verarbeitet werden?
Es nicht einfach Zahlen, oder Zeichenketten die verarbeitet werden, sonder komplexe Sachen, wie Repositorys, Verzeichnisstrukturen, oder Objektdateinen...
Re: Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Montag 18. Juni 2007, 12:45
von keppla
McEnroe hat geschrieben:Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
Indem du den Zielzustand mit dem Sollzustand vergleichst.
bei funktionen, die was zurückgeben (und keine nebeneffekte haben) ist das trivial, wie du schon selbst bemerkt hast.
funktionen, die nichts zurückgeben, und hauptsächlich nebeneffekte haben, lassen sich etwas schwerer testen.
ein test für eine funktion createfile(filename), die None zurückgibt, und eine datei anlegt, könnte so aussehen
Code: Alles auswählen
import os
import unittest
class MyTestCase(unittest.TestCase):
def test(self):
filename = '/tmp/testfile'
createfile(filename)
assert os.path.isfile(filename)
wenn du feststellst, dass du viele funktionen hast, die sich nur schwer testen lassen, kann (muss aber nicht) dass ein hinweis darauf sein, dass du dein Design überdenken solltest.
Ein "Gutes Design(tm)" ist in der (oder zumindest meiner) Idealvorstellung modular, und lässt sich gut testen, weil man jedes Element für sich testen kann.
Re: Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Montag 18. Juni 2007, 15:51
von EyDu
keppla hat geschrieben:Ein "Gutes Design(tm)" ist in der (oder zumindest meiner) Idealvorstellung modular, und lässt sich gut testen, weil man jedes Element für sich testen kann.
Aber so bald du Dinge wie Datenbanken, RPCs oder noch schlimmer: "echte Geräte", testen musst, ist das aber nicht mehr so einfach möglich. Die Testumgebung wir dann locker so groß wie das eigentliche Modul. Und diese Testumgebung muss natürlich auch noch mal getestet werden, wenn du eine gute Abdeckung haben willst, da sonst die Tests selber überflüssig sind.
@McEnroe:
Bei einem Szenarie wie bei dir, bietet es sich an, Teile der Schnittstelle des Repositories nachzubilden und dann in die zu testende Instanz einzuschleusen. Das ist bei Python doch sehr einfach möglich und vereinfacht das Testen enorm (mit Java will ich sowas nicht probieren...). Dein eingebrachtes Objekt hast du dann vollständig unter Kontrolle und kannst Exceptions werfen und Rückgabewerte erzeugen wie du möchtest.[/code]
Verfasst: Montag 18. Juni 2007, 17:51
von BlackJack
Für solche "Mock-Objects" gibt's auch Bibliotheken:
http://pmock.sourceforge.net/
Re: Unittesting - Was bei vielen "Void"funktionen?
Verfasst: Mittwoch 20. Juni 2007, 13:01
von keppla
EyDu hat geschrieben:keppla hat geschrieben:Ein "Gutes Design(tm)" ist in der (oder zumindest meiner) Idealvorstellung modular, und lässt sich gut testen, weil man jedes Element für sich testen kann.
Aber so bald du Dinge wie Datenbanken, RPCs oder noch schlimmer: "echte Geräte", testen musst, ist das aber nicht mehr so einfach möglich.
Klar, dass die Realität manchmal anders aussieht, deshalb schrieb ich von Idealvorstellungen.
Allerdings kann man, wenn man sich eben hübsch um Modularität bemüht, dann einfach den "untestbaren" bereicht ungetestet lassen, aber den Rest testen.
Davon ab gibts mittlerweile auch Testtools für schwertestbare Dinge, wie Webseiten, etc, mit denen man teilweise recht brauchbare ergebnisse erziehlt.
Imho sollte man beim Testen immer dran denken, dass man nicht einen Beweis führt, sondern nur Alarmanlagen anbaut.
Ein fehlerfreier Testlauf heist nicht fehlerfrei, sondern nur "keine der früheren Fehler gefunden".