Könnte Tipps rund ums Testen gebrauchen...

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

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 :wink: 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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
BlackJack

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.
Benutzeravatar
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 :-D
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

Hyperion hat geschrieben:Hast Du Dir denn schon Grundlagen über das (Unit-)Testing an sich angeeignet?
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.

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... :wink:

mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
BlackJack

@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.
Benutzeravatar
bwbg
User
Beiträge: 407
Registriert: Mittwoch 23. Januar 2008, 13:35

Ich werfe einfach mal test driven development (TDD) als radikalste Form des unittesting in den Raum. ;)
"Du bist der Messias! Und ich muss es wissen, denn ich bin schon einigen gefolgt!"
Antworten