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?
Unittesting - Was bei vielen "Void"funktionen?
-
lunar
die aber doch hoffentlich im Fehlerfall Ausnahmen auslösen, ansonsten kannst du ...McEnroe hat geschrieben:Dabei sind viele Funktionen "void"-Funktionen (d.h. Funktionen ohne Rückgabewert wie zum Beispiel "doSvnUpdate()").
... das nämlich nicht wirklich vernünftig testen.Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
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.lunar hat geschrieben:die aber doch hoffentlich im Fehlerfall Ausnahmen auslösen, ansonsten kannst du ...McEnroe hat geschrieben:Dabei sind viele Funktionen "void"-Funktionen (d.h. Funktionen ohne Rückgabewert wie zum Beispiel "doSvnUpdate()").
... das nämlich nicht wirklich vernünftig testen.Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
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...
Indem du den Zielzustand mit dem Sollzustand vergleichst.McEnroe hat geschrieben:Das Problem ist schnell umschrieben: Wie kann ich so etwas Unittesten?
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)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.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.
@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]
-
BlackJack
Klar, dass die Realität manchmal anders aussieht, deshalb schrieb ich von Idealvorstellungen.EyDu hat geschrieben: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.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.
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".