Test-Driven Development

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Edit (Leonidas): Vom Thread "Klasse mit statischen Attributen ?" abgetrennt.
Goswin hat geschrieben:Blackjack: Ich programmiere nicht deshalb in Python, weil Python perfekt ist oder ich es dafür halte. Ich kenne keine perfekte Programmiersprache, und mit einer Haltung wie du sie mir empfiehlst, könnte ich überhaupt nicht programmieren. Natürlich kann z.B. Java besser kapseln, aber dafür hat Java eben andere Nachteile. Nur, die Nachteile von Python wird man als Pythonprogrammierer doch wohl beim Namen nennen dürfen, und auch die beste Methode suchen dürfen, damit zu leben!
Ich kann mich dem, was Blackjack gesagt hat, nur anschließen. Python verfolgt die Philosophie "Der Programmierer weiss am besten, was er tut" sowie der Philosophie von Unittests: "Ungetesteter Code ist kaputter Code".
"Statische" Sprachen schränken den Programmierer ein, um eine Art von Fehlern zu verhindern. Viele (Logik-)Fehler hingegen können nicht erkannt werden. Für diese braucht man Unittests. Unittests erkennen aber die Art von Fehlern, die der Compiler erkennen kann. gleich mit. Warum also sollte der Compiler überhaupt die Prüfungen durchführen?

Um mal dein Beispiel aufzugreifen, sagen wir es gäbe eine Möglichkeit, "random.seed = 1" zu unterbinden. Dann wäre es doch nur logisch, den Fall abzufangen, dass man "a = foo" schreibt, obwohl man "a = foo()" meinte.

Damit verliert man aber auch die Möglichkeit, Funktionen zu übergeben oder muss dafür eine andere, explizitere Syntax einführen.

Das Problem mit einer "strengen" Sprache ist, dass der Compiler ein paar(!) Fehler erkennt und anmeckert, aber bei weitem nicht alle.

Und dadurch gewinnst du nichts: du musst trotzdem noch einen Unittest schreiben, um die Funktionalität zu testen. Viel schlimmer noch: die (teilweise) Überprüfung durch den Compiler gibt dir ein Gefühl von falscher Sicherheit, dass dich dazu verleiten kann, eben "diesesmal doch keinen Testcase zu schreiben", weil die Funktionalität ja so trivial ist.

In Python hingegen finde ich es ganz praktisch, dass du ein etwas mulmiges Gefühl hast, wenn du Code ohne entsprechenden Unittest schreibst. "Ungetesteter Code ist kaputter Code" ist hier viel offensichtlicher.

Jeder Programmierer hat eine eigene Programmierphilosophie, und wenn deine ist, dass es besser ist, wenn der Compiler dir ein bisschen auf die Finger schaut, dann gibt es genug Sprachen, die diese Philosophie teilen und du mit diesen besser aufgehoben bist! Dass soll nicht heißen, dass Python besser oder schlechter als andere Sprachen ist, sondern nur, dass die Philosophie eine andere ist.

Du bist am produktivsten, wenn du nicht "gegen die Sprache kämpfen" musst, weil sie die Dinge anders sieht als du. Ich z. B. habe dieses Problem bei Sprachen wie C++ und Java, eben weil ich deren Philosophie nicht ganz teile und programmieren in Python fühlt sich für mich eben natürlicher an. Wenn dass bei dir nicht der Fall ist, ist Python für dich wohl nicht die richtige/beste Wahl.

Ich denke dass ist, was Blackjack sagen wollte. (Er kann mich natürlich gerne korrigieren)

Edit (Leonidas): Vom Thread "Klasse mit statischen Attributen ?" abgetrennt.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Goswin hat geschrieben: Un da ich die Zufallszahlen nicht sofort überprüft habe, merke ich ziemlich viel später, dass meine Rechnungen nun nicht reproduzierbar sind. Dies ist nur eins von vielen Beispielen wo es besser wäre, alle Attribute einer Klasse von vornherein festzuschreiben.
Nein! Pass gefälligst auf oder nutze Code Vervollständigung! IMO ist das, was du bemängelst, eines der wichtigsten Merkmale dynamischer Sprachen bzw. sie machen sie erst zu solchen!
BlackJack hat geschrieben:Wenn Du das so siehst, solltest Du nicht in Python programmieren.
Sehe ich auch so.
Goswin hat geschrieben:mit einer Haltung wie du sie mir empfiehlst, könnte ich überhaupt nicht programmieren[/b].
Ja, und? Was erwartest du? Du nutzt eine dynamische Sprache und beschwerst dich über Merkmale die sie gerade zu dem macht? Das ist so wie wenn ich Haskell programmiere und sage "Muss dieser ganze funktionalen scheiß sein? Geht es nicht auch OO und Imperativer?".
Goswin hat geschrieben:Natürlich kann z.B. Java besser kapseln, aber dafür hat Java eben andere Nachteile. Nur, die Nachteile von Python wird man als Pythonprogrammierer doch wohl beim Namen nennen dürfen, und auch die beste Methode suchen dürfen, damit zu leben!
Wie gesagt, das was du als Nachteil beschreibst in eines der vorteile von Python und anderen dynamischen Sprachen wie z.B. Ruby. Und Ruby ist da sogar weit aus heftiger da du da sogar Builtin-Classes änder kannst und viel mehr scheiße anrichten kannst :). Muss man halt aufpassen was man macht.
Sprich: Das denken muss immer noch der Programmierer übernehmen (und soll es auch) und gefälligst aufpassen was er macht!

Das ist meine Meinung und dazu stehe ich, auch wenn es hart rüberkommt.

Außerdem sind Joghurts Ausführungen absolut in jedem Punkt richtig!

Auch das was alle hier über Unittest (Coverage nicht vergessen) gesagt wurde, ist für dynamischen Sprachen um so wichtiger und ist unabhängig davon sowieso für **jedes** ernsthaftes Projekt angebracht! Ich gehe sogar soweit - wie es Joghurts ganz dezent angedeutet hat - das ich jeden Code ohne Unittest als potenziellen kaputten Code ansehe (Trivial code ausgenommen)! Und was ich von Code ohne Coverage halte kann man sich ja denken ;) Irgendwo toter Code vorhanden ...
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

@poker: Coverage hatte ich bisher noch nie gehört. Nach ein bisschen Googlen weiß ich jetzt aber wohl, worum es dabei geht. Für Python habe ich dazu coverage.py gefunden. Arbeitest Du damit? Was verwendest Du ansonsten? Wie machst Du das dann vom Programmierablauf her?
MfG
HWK
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Ned Batchelders `coverage.py` wird meines Wissens in einem der Pocoo-Projekte, ich meine (u.a.) in Pygments, verwendet. Schau doch mal in die Repositories für ein Beispiel, wie es eingebunden werden kann.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Siehe die "coverage"-Einstellung unter http://dev.pocoo.org/hg/pygments-main/f ... sts/run.py.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

Danke! Coverage.py und das "Pocoo-Testfile" werde ich mir mal genauer anschauen.
MfG
HWK
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

HWK hat geschrieben:@poker: Coverage hatte ich bisher noch nie gehört. Nach ein bisschen Googlen weiß ich jetzt aber wohl, worum es dabei geht. Für Python habe ich dazu coverage.py gefunden. Arbeitest Du damit? Was verwendest Du ansonsten? Wie machst Du das dann vom Programmierablauf her?
MfG
HWK
Hi.

Ich nutze figleaf das auf Ned Batchelder coverage.py basiert. Es entspricht zum größten teil Ned Batchelder Implementierung und wurde nur ein wenig aufgebohrt (reporting, etc). Bevor ich figleaf kannte habe ich ``coverage.py`` genutzt.

Zu der Frage was ich sonst noch nutze: Für die Unit tests finde ich IMO py-test am besten.

Für teile die man schlecht Unit testen kann nutze ich Mock-Objekt: http://python-mock.sourceforge.net/
Das ist aber bisher so gut wie garnicht bei mir vorgekommen.


Für alle die den Thread entdecken und nicht wissen wozu man sowas Braucht:
Die Notwendigkeit von einem Abdeckungstest (Coverage) liegt ja darin begründet um "toten Code" (Nicht vom Unit test getestet) zu identifizieren um dann dafür einen Unit test zu implementieren bzw. zu erweitern. Sprich, erst ein Anschließender Coverage gewährleistet das die Unit tests auch vollständig sind und machen daher das schreiben von vollständigen Unit tests erst möglich!

Für gewöhnlich läuft das in Python so, das man Unit tests schreibt und alle beteiligten zu testenden Komponenten importiert. Nach Fertigstellungen und starten der Unit test erfolgt danach ein start des full Coverage test. Durch den vom Coverage test erzeugten Report kann man dann die Bereiche sehen die nicht ausgeführt wurden.

Beispiel: Nähmen wir folgenden Triviale Funktion:

Code: Alles auswählen

class FoobarError(Exception): pass

def foobar(para):
    if not isinstance(para, basestring):
        raise ValueError()
    ...
    if ...
    elif ...
    else:
        raise FoobarError()
Wenn wir jetzt ein Unit test für foobar schreiben und den Unit test starten mit anschließenden Coverage, macht Coverage folgendes: Coverage Untersucht ob der Unit test die Funktion ``foobar`` in allen möglichen Varianten aufgerufen hat, so das alle möglichen Verzweigungen von ``foobar`` einmal aufgeruffen wurden. Wenn dabei rauskommt das einige Verzweigungen nicht aufgeruffen wurden (in diesem Beispiel das offensichtlichste der isinstance test, das einige wohl nicht testen werden), taucht das in dem von Coverage erzeugten Report auf, mit den Code stellen.

Dieses Verfahren des implementieren von Unit test und das spätere pflegen dieser, nimmt einen Entwickler sehr viel arbeit ab und gehört IMO für mich zum guten Ton :)

Für die, die sich mit der Thematik ein wenig mehr beschäftigen wollen, sein diese Seite empfohlen, die kompakt das Thema erklärt.

edit:Alle die Wissen wohlen wie man für GUI Anwendungen Unit testet schreibt, sei diese Seite empfohlen. Ist zwar auf wxPython bezogen, lässt sich aber auch für andere benutzen, da dort nur allgemein beschrieben wird wie man vorgehen kann.
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

poker hat geschrieben:Zu der Frage was ich sonst noch nutze: Für die Unit tests finde ich IMO py-test am besten.
Ich möchte auch noch nose in die Runde werfen
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Ein paar (meinetwegen auch reallife-)Beispiele zum Testen von Datenbank- und Socket-Zugriffen würden mich brennend interessieren. Ich habe mir zwar die zahlreichen Python-Mock-Implementierungen sowie Ressourcen wie z.B. Googles Testing-Blog angesehen, aber so *richtig* komme ich da auf keinen grünen Zweig.

Achso, `py.test` nutze ich ebenfalls, da ich sehr schätze, dass es keine Vererbung voraussetzt und hübsch selbst alle Testmodule und -Callables findet. In irgendeinem Blog wurde es mit `unittest` und `nose` verglichen und `unittest` kam am besten weg - da kommt es allerdings immer auf die Anforderungen an, und mir ist letzteres einfach zu umständlich. Wenn einen das Framework schon vom Schreiben von Tests abhält, its das schon mal schlecht, gerade beim Einstieg in die Materie.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

@poker: Bedeutet das, dass durch Unittests jede Zeile des Programmcodes mindestens einmal ausgeführt werden soll? Ist das nicht ein bisschen aufwendig und in vielen Fällen auch unnötig?
BlackJack

Genau in den Zeilen wo Du denkst es wäre unnötig, verstecken sich am Ende die Fehler. ;-)

Die Zeilen, die bei normaler Benutzung des Codes ausgeführt werden, lassen sich auch leicht von Unittests abdecken, das passiert ja nahezu automatisch. Die anderen, eher besonderen Fälle sollte man dann aber auch testen. Habe zum Beispiel schon öfter Quelltext gesehen wo irgendwelche Fehlerbedingungen abgeprüft wurden, und diese Prüfungen fehlerhaft waren. Hat bloss nie jemand gemerkt weil die entsprechende Fehlersituation in der Praxis nicht aufgetaucht ist. Oder vielleicht doch, und es hat wegen der fehlerhaften Prüfung nur keiner gemerkt.
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

HWK hat geschrieben:Bedeutet das, dass durch Unittests jede Zeile des Programmcodes mindestens einmal ausgeführt werden soll?
Ja. Und das natürlich auch mit sinnvollen Testwerten.
HWK hat geschrieben:Ist das nicht ein bisschen aufwendig und in vielen Fällen auch unnötig?
Wenn deine Anwendung ihre Arbeit korrekt (so korrekt wie es eben menschenmöglich ist :-) ) machen soll bleibt dir nichts anderes übrig. Spätestens wenn du größere Änderungen machen musst, was ja immer mal wieder vorkommt, bewährt sich der zusätzliche Aufwand.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

Schluck! Und das als Hobby-Programmierer. Dann muss man sich wohl vorher gut überlegen, bei welchen seiner kleinen oder großen selbstprogrammierten Helferlein dieser Aufwand gerechtfertigt ist.

Ich versuche gerade, mich weitergehend über das Testen zu informieren. Im Python-Manual wird unter 5.4.1 Writing Unit Tests for the test package auf das Buch Test Driven Development von Kent Beck verwiesen. Lohnt sich das?
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

HWK hat geschrieben:Bedeutet das, dass durch Unittests jede Zeile des Programmcodes mindestens einmal ausgeführt werden soll? Ist das nicht ein bisschen aufwendig und in vielen Fällen auch unnötig?
"Ungetester Code ist falscher Code" -> "Ungetestete Zeilen sind falsche Zeilen"

Der Vorteil von Unittests macht sich dann bemerkbar, wenn du Refaktorisiert; sobald die Tests durchlaufen, kannst du ziemlich sicher sein, dass sich das Programm so verhält wiei vorher (wenn nicht, waren deine Unittests nicht ausreichend)

Übrigens sollte man Unittests immer erweitern; jeden Bug den man findet, sollte man in einen Unittest packen und dann den Bug fixen. Sobald der Test durchläuft, ist der Bug gefixt und man kann sicher sein, dass er nicht nochmal auftritt.
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

HWK hat geschrieben:Schluck! Und das als Hobby-Programmierer. Dann muss man sich wohl vorher gut überlegen, bei welchen seiner kleinen oder großen selbstprogrammierten Helferlein dieser Aufwand gerechtfertigt ist.
Unittests sind dazu da, dir das Programmiererleben zu erleichtern. Sobald du ein Programm hast, was du oder andere später warten müssen, lohnen sie sich. Für einen kleinen Hack, der kurz eine Arbeit machen soll und danach weggeschmissen wird, macht es dementsprechend keinen Sinn, Unittests zu schreiben, weil du insgesamt mehr Zeit brauchst, um das Programm während seiner ganzen Lebensdauer (die sehr kurz ist) zu warten/am laufen zu halten.


Wenn du dir hingegen ein kleines Tool schreibst, dass meinetwegen bestimmte Dateien sichert, macht es Sinn, Tests zu haben, da du das Programm u.U. später mal erweitern wirst und du spätestens dann eh Test schreiben solltest.
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

Joghurt hat geschrieben:Wenn du dir hingegen ein kleines Tool schreibst, dass meinetwegen bestimmte Dateien sichert, macht es Sinn, Tests zu haben, da du das Programm u.U. später mal erweitern wirst und du spätestens dann eh Test schreiben solltest.
Ja, vielleicht sollte man die Tests schreiben, wenn man ein Programm erweitert. Das scheint doch eine sinnvolle Abgrenzung zu sein, ob sich Testing lohnt.

Wo seht Ihr die Vorteile von py-test bzw. nose gegenüber unittest?

Kennt denn jemand das Buch Test Driven Development von Kent Beck?

MfG
HWK
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

HWK hat geschrieben:@poker: Bedeutet das, dass durch Unittests jede Zeile des Programmcodes mindestens einmal ausgeführt werden soll? Ist das nicht ein bisschen aufwendig und in vielen Fällen auch unnötig?
Hi, das ist ne gute berechtigte Frage.

Ich sehe es so wie BlackJack und Eydu.

Der am Unit tests gekoppelte Coverage soll dir als Programmierer in erste Linie die lästige Arbeit abnehmen zu identifizieren, ob du alle benötigten Fälle (Die du für wichtig erachtest) abgedeckt hast. Bei sehr großen Anwendungen vergisst man immer wider mal für wichtige Bereiche seiner Software Unit tests zu schrieben, weil es eben Umfangreich, komplex und unübersichtlich wird[1].

Der Coverage soll dir also die Arbeit abnehmen die Bereiche zu identifizieren die noch nicht durch Unit tests angedeckt wurden[2]. Anschließend kannst du anhand des erzeugten Reports entscheiden, welche dingen deiner Meinung nach unbedingt abgedeckt werden müssen und welche für dich vernachlässigbar sind. Vernachlässigbare dingen könnten z.B. wirkliche Trivialfunktionen sein die ehe nicht mehr geändert werden und "immer" funktionieren. -- Aber wie BlackJack schon richtig angedeutet hat, der Teufel liegt im Detail ;) Oft sind es nämlich genau die dinge wo man denkt "braucht man nicht passt schon" und dort verstecken sich Fehler. Daher versuche ich meistens (je nach Komplexität der Software) eine 100%ige Abdeckung zu erreichen.

[1]: Und meistens ist es ja so das man Unit tests nicht parallel zur eigentlichen Software schreibt sondern erst viel später = Wochen oder gar Monate danach. Es sein den man nutzt Testgetriebene Entwicklung, wo erst die Unit tests geschrieben werden und dann die jeweiligen Sachen implementiert werden.

[2]: Solche bereiche sind ja nicht nur innerhalb einer Funktion, sondern stellen den ganzen Module space dar: Sprich, auch Funktionen für die überhaupt noch kein Unit test existiert, werden dir durch den Coverage angezeigt. Also z.B. wenn ich Modul ``foobar`` habe in denn ``foo`` und ``bar`` ist und ich nur einen Unit test für ``foo`` geschrieben habe, zeigt der anschließende Coverage mir an, das ``bar`` vom unit test Modul nicht ausgeführt (=getestet) wurde. :)

---

Y0Gi hat geschrieben: Achso, `py.test` nutze ich ebenfalls, da ich sehr schätze, dass es keine Vererbung voraussetzt und hübsch selbst alle Testmodule und -Callables findet. In irgendeinem Blog wurde es mit `unittest` und `nose` verglichen und `unittest` kam am besten weg
Ich schätze das war dann folgender Blog:
http://agiletesting.blogspot.com/2005/0 ... ttest.html
http://agiletesting.blogspot.com/2005/0 ... ctest.html
http://agiletesting.blogspot.com/2005/0 ... -tool.html
Y0Gi hat geschrieben:Ein paar (meinetwegen auch reallife-)Beispiele zum Testen von Datenbank- und Socket-Zugriffen würden mich brennend interessieren. Ich habe mir zwar die zahlreichen Python-Mock-Implementierungen sowie Ressourcen wie z.B. Googles Testing-Blog angesehen, aber so *richtig* komme ich da auf keinen grünen Zweig.
Die frage bei deinem Beispiel "Datenbank- und Socket-Zugriffen" ist, was genau deine Software macht? Wenn deine Software nur die Bestandteile nutzt (Die nicht von dir geschrieben sind), dann musst du die auch nicht testen! Es ist nämlich nicht deine Aufgabe auch fremde Libraries mit deinen Unit tests abzudecken. Dafür bittet es sich dann an Mocks zu schreiben.

Angenommen du hast eine Funktion oder Klasse die über `socket` auf sockets zugreift und in Abhängigkeit der Ergebnisse bestimmte Aktionen ausführt oder Zustände ändert. Jetzt kommt das Problem, das wenn du damit auf einen Externen $SERVER zugreifen der immer Bestimmte Daten zurückliefern muss. In dem Fall abstrahierst du `socket` und die erwarteten Daten von $SERVER in dem masse das deine Funktion genauso Arbeitet, als wenn du Tatsächlich `socket` mit $SERVER nutzen würdest.
Das heißt konkret, das du die erforderlichen Schnittstellen von `socket` nachschreibst die sich halt stat sich mit $SERVER verbindet, eben nur die von dir von echten $SERVER erwarteten Daten zurückliefert. Das ganze ist dann zuzusagen ein Mock - Eine Attrappe - den du deiner Funktion unterschiebst. Natürlich musst du diese Attrappe soweit nachbauen das auch die von dir erwarteten Fehler Codes/Exception wie beim Original geschmissen werden.

Und genau hier fängt es an kompliziert zu werden. Das Thema ist wirklich nicht gerade trivial, und man kann da schnell an die Grenzen des machbaren (=Verhältnismäßigkeit) kommen. Nicht um sonst kann das schreiben einer Testumgebung schnelle mal umfangreicher und komplexer werden, als die zu testenden Umgebung. Hier muss man eben von Fall zu Fall zwischen Nutzen und Verhältnismäßigkeit abwägen.

Dan sollte man noch beachten ob die Software in einer Sicherheitsrelevanten Umgebung Einsatz findet. Dort sollte, IMO, sicherheitsrelevante Bereiche garnicht mit Mocks getestet werden, sondern eine Real existierende speziell dafür geschlafene Testumgebung eingerichtet werden.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Was im Zusammenhang von Unit tests die 100% alles abdecken noch interessant ist, ist die Tatsache das Unit tests sozusagen auch gleichzeitig eine Spezifikation darstellen. Den sie spezifizieren (Abstrakt) ja schon die ganze Schnittstellen bis ins kleinste Detail; wenn auch nur für den Programmierer lesbar.

In dem Zusammenhang wäre es Interessant wenn es Programme geben würden, die daraus auch gleich eine Spezifikation in lesbarer Form generieren würden :D Bisher kann man sich so behelfen, in den man für Jeden Testcase docstrings schreibt die genau (Jedes Detail) beschreiben was der Testfall macht, und man ein Programm erzeugt der daraus eine Spezifikation erzeugt :D

Klingt witzig, ist aber durchaus ernst gemeint ;) Im Ruby lager gibt es durchaus (vereinzelt) schon Überlegungen in dieser Richtung. Auch gibt es da ein Unit testing Packet das nicht von Unit tests schreiben redet, sondern von Spezifikationen schreiben :D -- Ok, kann kein Schwein lesen außer die, die die "Spezifikationen" geschrieben haben oder eben die Ruby nerds :twisted:
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

poker hat geschrieben:Anschließend kannst du anhand des erzeugten Reports entscheiden, welche dingen deiner Meinung nach unbedingt abgedeckt werden müssen und welche für dich vernachlässigbar sind.
Das klingt ja schon etwas realitätsnäher.
poker hat geschrieben:Ich schätze das war dann folgender Blog:
Ich hab's mir mal angeschaut. Für mich als Einzelkämpfer scheint doctest durchaus interessant zu sein. Kann noch jemand etwas zu nose sagen und natürlich zum Buch Test Driven Development von Kent Beck?
MfG
HWK
Benutzeravatar
Goswin
User
Beiträge: 363
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen
Kontaktdaten:

Vielen Dank für eure Anmerkungen und Vorschläge. Ich kann mich derzeit aber noch nicht dazu äußern, weil ich bisher nur einen Teil der Python-Möglichkeiten in meinen Programmen verwendet habe und mir vieles davon noch unbekannt ist. Wenn ich Metaklassen und ähnlich Tiefschürfendes beherrsche und dabei etwas mehr Erfahrung gewinne, werde ich wahrscheinlich darauf zurückkommen wollen.
Antworten