Hallo,
ich bekenne reumütig, mich bisher nicht wirklich mit Tests befasst zu haben. Ich habe mein Zeugs mit ein paar Werten gefüttert und geschaut, ob die Rückgabewerte stimmten.
So langsam ist mir das aber echt zu umständlich und ich muss mich wohl oder übel mit der Materie 'Test' befassen. Nachdem es allerdings sehr viele Formen bzw. Module gibt, wäre mir Euer Rat eine große Einstiegshilfe.
Beginnen möchte ich mit meinen Wiederholungsklassen. Ich habe z. B. eine `MonthlyRecurrence` mit einer `query` Methode. Dieser Methode übergebe ich ein `scope`-Exemplar, welches einen bestimmten Zeitraum darstellt und erhalte als Ergebnis alle monatlichen Wiederholungen innerhalb dieses scopes.
Wie gesagt, mein Code ist völlig Test-jungfräulich. Welches Testmodul würdet ihr verwenden, um genannte Wiederholungsabfragen zu testen?
mutetella
Könnte Tipps rund ums Testen gebrauchen...
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
Ich persönlich habe bisher immer `nose` oder `py.test` verwendet. Zumindest früher war das alles immer ein wenig leichtgewichtiger als das *Unit-Rahmenwerk aus der Standardbibliothek. Habe dort aber schon länger nicht mehr in die Neuerungen geschaut ob sie's mittlerweile ein wenig „pythonischer” gemacht haben.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hinzu käme dann noch eine Mocking-Lib; ich kann da unter Python noch keine Empfehlung abgeben. Evtl. kommt man in Python aber auch gut ohne aus...
Hast Du Dir denn schon Grundlagen über das (Unit-)Testing an sich angeeignet? Das ist ja eigentlich wichtiger als die spezielle Bibliothek... zumindest zum Anfang
Hast Du Dir denn schon Grundlagen über das (Unit-)Testing an sich angeeignet? Das ist ja eigentlich wichtiger als die spezielle Bibliothek... zumindest zum Anfang
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Nein, außer mal ein wenig die Dokumentationen von `py.test`, `nose` und `unittest` überflogen. Mehr als ein Bauchgefühl, das mir `py.test` irgendwie "handlicher" erscheinen lässt, hab' ich davon nicht bekommen.Hyperion hat geschrieben:Hast Du Dir denn schon Grundlagen über das (Unit-)Testing an sich angeeignet?
Ehrlich gesagt verstehe ich schon gar nicht, weshalb man denn überhaupt ein Test-Modul verwendet. Warum nicht einfach ein paar Testfunktionen, die verschiedene ``assert``'s durchführen? Oder einfach nur die Ergebnisse von ``result in valid_results``?
Aber ok, ich werd' jetzt einfach mal ein wenig herumspielen und geh' davon aus, dass sich auch mir dieses Testzeugs noch erschließen wird. Jeder sagt, "... das musst Du unbedingt machen!", mich nerven meine händischen Tests, also irgendwas muss ja dran sein...
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
@mutetella: Bei `nose` und `py.test` läuft es doch genau darauf hinaus, ein paar Test-Funktionen mit ein paar ``assert``\s. Im Grunde bleibt es dabei das Du Deine Funktionen „per Hand” mit Testdaten fütterst, nur dass es mit UnitTests aufgeschrieben wird und wiederholbar ist. Das jeweilige Rahmenwerk sucht sich dann alle Tests zusammen, anhand der Funktions- und Klassennamen und/oder Dekoratoren die Tests markieren und führt die alle aus. Am Ende fällt eine nette Übersicht raus wieviele Tests durchgeführt, bestanden, oder halt nicht bestanden wurden.
Vorteil zum manuellen Testen: Wenn etwas am Code geändert wurde, kann man die selben Tests mit einem einzigen Kommando wiederholen und schauen ob der Code immer noch durchläuft. Und wenn man Fehler findet oder gemeldet bekommt, kann man erst einen Test schreiben, der das Problem auslöst, und dann den Fehler beheben. So ist man sicher das man in a) behoben hat, und das es b) auffällt wenn man ihn irgendwann aus versehen wieder einbaut.
Vorteil zum manuellen Testen: Wenn etwas am Code geändert wurde, kann man die selben Tests mit einem einzigen Kommando wiederholen und schauen ob der Code immer noch durchläuft. Und wenn man Fehler findet oder gemeldet bekommt, kann man erst einen Test schreiben, der das Problem auslöst, und dann den Fehler beheben. So ist man sicher das man in a) behoben hat, und das es b) auffällt wenn man ihn irgendwann aus versehen wieder einbaut.