TDD ist keine Wissenschaft!
In letzter Zeit wird viel über TDD geredet und diskutiert. Das ist gut, denn offensichtlich gibt es da noch einiges zu besprechen und zu lernen. Ich habe erst kürzlich gelernt, dass es absolut sinnlos ist, bestehende Projekte ohne TDD anzugehen. Auch wenn ich viele Tests im nachhinein schreibe. Ich schreibe sie einfach so wie ich die Anforderungen verstanden habe. Mal nähert sich der Code an die Tests, mal die Tests an den Code. Das schöne daran ist, dass man wesentlich schneller den bestehenden Code versteht und auch deren Schwachstellen identifiziert. Dadurch wird auch die Wartung des Brownfield-Projektes gestärkt. Innerhalb von kurzer Zeit kann ich Aufwände und Problemstellungen gut einschätzen.
TDD im Rampenlicht
Naja, das nur nebenbei. Mir geht es eigentlich um ein anderes Thema. Mir geht es um etwas Generelles. Als Pete und ich mit den .NET Coding Dojos angefangen haben, gab es positive Resonanz. Es wurden Dojo’s veranstaltet und Code Kata’s exerziert. Super! Meiner Ansicht nach kam TDD dadurch ein kleines Stück mehr in’s Rampenlicht als es schon durch Clean Code Developer bereits war. In zahlreichen Posts gab es Diskussionen um die Sinnhaftigkeit von Unit Tests, die Kata Berichte und grundlegender Erkenntnisse über TDD. Eine besonders positive Sache, denn Weiterentwicklung und Entdeckung sind schöne Dinge.
Doch eine Sache stört mich. Manchmal stört es mich sogar gewaltig. Dieses Trara und Tamtam um TDD und Beeinflussung des OO-Designs durch Tests und das Entkoppeln von Zustand. Bei dem einen oder anderen Post kann ich mir das Kopfschütteln während des Lesens einfach nicht verkneifen. Die Spitzfindigkeit und unnötige Verkomplizierung einfacher Sachverhalte geht mir zuwider. Für manch einen mag es Anspruch sein, über ein Feuerwerk an Eloquenz einfachste Dinge mit fesselnden Trapezschwüngen der Rhetorik auf das Hochseil des Softewareentwicklungszirkusses zu katapultieren. Die lufterhitzenden Spots, der nervöse Trommelwirbel, der adrenalisierende Schweiß der Konzentration inklusive. Für manch einen. Für mich jedenfalls nicht.
Im Gegenteil. Es stört mich. Es irritiert mich. Denn mich interessiert das Thema selbst. Ich denke es Bedarf keines jonglierens mit DIP, SRP, YAGNI, DRY, um wirklich im Alltag der Software-Entwicklung gut bestehen zu können. Man darf mich hier nicht falsch interpretieren. Auch ich finde es wichtig, sich mit “Dependency Inversion”, “Single Responsibility”, “Decisions on Last Responsible Moment” und “Repetition Avoidance” auseinanderzusetzen, damit umzugehen und täglich einzusetzen.
TDD ist keine “Rocket Science”
Doch man kann es übertreiben. Die ständige, gestelzte und wie ein Ritus sich selbst auferlegte “Tagesreflexionsprogramm” ist meines Erachtens nicht förderlich. Überspitzt betrachtet ist es genau dasselbe wie das Bart-Simpson-Einhämmerungs-Ritual “Ich werde keinen Zustand testen!” – repetitiv, jedoch nicht kognitiv. 
Wer’s mag, kann ruhig jeden Tag nicht nur Selbstreflexion betreiben, sondern auch jeden Tag ein Code Kata lösen, damit die Entwicklerseele rein wird. Ich jedenfalls werde das nicht tun.
Ich arbeite auch nach Prinzipien, löse Probleme auch mit Patterns und programmiere neben dem Tagesgeschäft ab und an auch mal Code Kata’s. Aber ich bin mir gleichermaßen bewußt, das ich jedes Mittel und Werkzeug richtig einordnen und im richtigen Maß anwenden muss, damit es mich langfristig weiterbringt.
Gleiches gilt für mich auch beim Thema TDD. Ich arbeite nun seit etwas mehr als einem halben Jahr stringent mit TDD. Zuvor habe ich es immer ab und an eingesetzt, aber nie “ernsthaft” betrachtet. Ich finde TDD (und auch BDD) sind eine besonders gute Methodik, um das V in EVA groß schreiben zu können. Es stärkt wunderbar die logischen Bestandteile der Anwendung und fördert mit der granularen Testanforderung lose Kopplung und komponentenorientiertes Design. Mittlerweile ist TDD für mich fester Bestandteil jeder Entwicklungsaufgabe.
Während der ersten Phase, in der ich TDD konsequenter eingesetzt habe, habe ich auch einiges darüber gelesen und durch das “Doing” auch vieles gelernt. So ist es z.B. überhaupt nicht schlimm, wenn man statusbehaftete Tests an den Enden der Datenverarbeitung macht. Konkret: Auch statusbasierte Tests sind ok, vor allem in Richtung DB oder UI. Ein schönes Beispiel dafür ist KataFizzBuzz als WinForms-Anwendung oder KataBlog. Natürlich ist interaktionsbasiertes Testen “schöner”, fördert die lose Kopplung und die isolierte Verifikation. Doch hier gibt es kein Schwarz oder Weiß. Es geht um den Einsatzbereich. Am Rand des Datenstroms ist man mehr statusbasiert, in der mitte eben mehr interaktionsbasiert. Außerdem ist das Thema Statustests vs. Interaktionstests ein relativ “alter Hut”. Schon mit Mocks Aren’t Stubs hat Fowler klar gemacht, dass beides in Ordnung ist.
Diese Zustands-Geschichte ist jedoch nur ein Beispiel. Es gibt da noch einige andere Klassiker: Kapselung, Verkettung, Referentielle Transparenz. Doch ungeachtet dieser Dinge, ist TDD keine Rocket Science. Im Gegenteil, TDD ist in der Kernaussage und Grundregeln so einfach, das sich die anderen “Problemstellungen” automatisch ableiten und auflösen. Gerade deswegen ist es meiner Meinung nach so wichtig, die Dinge einfach zu erklären und und diese “Leichtigkeit” auch zu transportieren. Die Code Kata’s von Dave sind ein Beispiel. Sie sagen nicht “Mach dies! Beachte das!”. Nein, sie sind eigenständige Probleme, auf deren Lösungsweg man individuell und für sich eine gute Lösung findet. Daraus ergeben sich automatisch mit der Zeit Verbesserungen und Erkenntnisse.
Fazit: Beim Verständnis und der Anwendung von Test-Driven-Development gilt, obgleich TDD ein bis Dato empirisch betrachtetes, jedoch theoretisch nicht ausreichend erforschtes Vorgehensmodell ist, das Prinzip von Ockhams Rasiermesser. Der praxisorientierte, frequentive Einsatz sowie das Erkennen der Grundtheoreme der TDD-Methodik sind das Fundament für den erfolgreichen Einsatz.
Und wenn ich das für alle diejenigen, die wie ich auch in der Kommunikation Wert auf Einfachheit legen, mal übersetzen darf:
TDD ist keine Wissenschaft!
Man kann viel darüber Lesen. Das ist auch gut. Besser ist es jedoch, TDD zu machen! Nicht viel über “dies und das” nachdenken. Die Devise lautet: “Mach es einfach, aber nicht einfacher“. Es wird von alleine gut und mit der Zeit sogar besser werden.
Hallo Ilker,
ehrlich gesagt kann ich Deine Aufregung nicht nachvollziehen. Du schreibst
“Bei dem einen oder anderen Post kann ich mir das Kopfschütteln während des Lesens einfach nicht verkneifen. Die Spitzfindigkeit und unnötige Verkomplizierung einfacher Sachverhalte geht mir zuwider.”
und deutest damit an, die Gedanken, die Ralf und ich uns machen, seien letztlich überflüssig – wir sollten statt so viel über die i-Tüpfelchen zu diskutieren uns eher daran machen, Tests einfach durchzuführen.
Einen Aspekt übersiehst Du dabei meines Erachtens allerdings: Ich (ich ganz persönlich) möchte mir Arbeit nur sehr ungerne öfter als ein Mal aufhalsen. Deshalb möchte ich vorher (!) wissen, worauf ich mich einlasse und mir vorher (!) ein durchdachtes Konzept erarbeiten, an dem ich mich orientieren kann.
Dazu zählt nun mal, gewisse Vorbehalte zu hinterfragen, offene Fragen zu klären und gegebenenfalls auch “akademische” Themen zu diskutieren. Nein, TDD ist keine Wissenschaft – es ist aber auch kein pragmatisches “Wir legen mal irgendwie drauf los” … damit ist nämlich spätestens dann, wenn man nicht mehr alleine, sondern im Team entwickelt, niemandem mehr geholfen.
Klare Regeln helfen, sich auf das Wesentliche zu konzentrieren.
Warum ich klare Regeln für dermaßen wichtig erachte, habe ich bereits in http://www.des-eisbaeren-blog.de/post/2009/08/27/Wozu-uberhaupt-Programmierstandards.aspx und in http://www.des-eisbaeren-blog.de/post/2009/08/26/Accuracy.aspx erläutert. Man mag dies für kleinlich oder pedantisch halten – ich würde dies “ordentlich” nennen.
Wenn Du Dir über die Tragweite Deines Handelns (in diesem Fall der Struktur und der Architektur Deiner Tests und damit verbunden auch Deiner Anwendung) nicht im klaren bist, keine klaren Regeln definiert hast – wie willst Du dann sauber und strukturiert entwickeln?
Viele Grüße,
Golo
Hi Golo,
nun, ich sage mit nichten dass Deine Gedanken überflüssig sind. Ich finde es sogar wertvoll. Du bist ein erfahrener Entwickler mit einem gewissen analytischen Niveau. Es ist immer hilfreich, sich vorab ein paar Gedanken zu machen – sei es nun über die Methodik oder über das Vorgehen selbst.
Was ich nur zum Ausdruck bringen möchte ist, dass wir gemeinsam versuchen sollten die Sachverhalte (für TDD und auch bei anderen Dingen) klar und einfach rüberzubringen. Ich kann mir gut vorstellen, dass manch einer sich beim Lesen ds einen oder anderen Posts denkt “Man ist das kompliziert, dieses TDD”. Dabei ist es nicht kompliziert. Es ist einfach. Das ist alles was ich sagen will.
Ich arbeite tagtäglich mit mehreren Teams zusammen und bin mir der Wichtigkeit vom Konventionen und Grundregeln bewußt. Jedoch ist es auch Fakt, dass in Teams gerne Konzeptdiskussionen zu lange dauern – ein Zeichen von zuviel “Upfront Thinking” (um es themenneutral auszudrücken).
Zu dem Thema Architektur von Tests und deren Anwendung gibt es viele Aspekte, einige davon müssen sicherlich vorher zu Ende gedacht sein, andere wiederum müssen es nicht. Insofern kann man TDD auch als Treiber für “Decisions On Last Responsible Moments” (http://www.codinghorror.com/blog/archives/000705.html) betrachten.
Auf bald,
Ilker
Hallo Ilker,
okay – dann hatte ich Deinen Eintrag falsch interpretiert.
Dass wir gemeinsam versuchen sollten, Sachverhalte klar und einfach zu vermitteln – dem stimme ich zu. Und auch Deiner Aussage, TDD sei einfach, stimme ich zumindest in technischer Hinsicht zwar nicht immer, aber doch häufig zu.
Dabei stellt sich aber auch schon wieder die Frage: Einfach für wen? Für einen OOP- und architekturerfahrenen Entwickler sicher, für Programmiereinsteiger wird es schon wieder schwieriger: Wenn ich nämlich nicht gewöhnt bin, meinen Code sauber zu strukturieren, ihn aufzubrechen, SoC zu betreiben, … dann wird das konsequente Einsetzen von TDD schwierig.
Das soll keine Entschuldigung sein, es nicht zu tun, und das soll auch nicht heißen, dass Einsteiger sich deshalb mit TDD nicht befassen sollten – aber der Begriff “einfach” ist eben relativ.
Was ich aber insbesondere nicht einfach finde, ist ein tragfähiges Konzept zu finden, für all das, was über den rein technischen Aspekt hinausgeht. Das sind dann so simple Fragen wie
- Darf / sollte ich Code anpassen, nur der Testbarkeit wegen?
- Wie organisiere ich meine Tests überhaupt, ohne den Überblick zu verlieren?
- Wo enden Unittests, wo beginnen Integrationstests?
- Woher weiß ich, dass ich alle wichtigen Fälle durch Tests abgedeckt habe?
Diese Fragen mögen abschrecken, weil sie schwierig erscheinen. Doch ich finde es wichtig, sich mit ihnen zu befassen, um ein umfassendes Bild vom Thema Unittests zu erhalten, um nicht nur zu wissen, was man machen muss, sondern auch, wie man es gut machen kann.
Und dafür sind diese Fragen meiner Meinung nach unerlässlich.
Interessant ist, dass man von 99% der Leute, mit denen man über Tests spricht, zu hören bekommt, man solle sich darüber nicht so viele Gedanken machen, oder eben – wie Roy Osherove es in seinem Buch “The Art of Unit Testing” geschrieben hat – “Don’t be silly.”
Das ist aber keine Antwort, das ist eine Abfertigung. Wer – als Einsteiger oder als Profi – wissen möchte, *warum* er XYZ so und nicht anders machen sollte, der *MUSS* sich mit solchen Fragen auseinandersetzen.
Viele Grüße,
Golo
Wo ich die Stirn runzeln mußte, war deine Bemerkung zur Reflexion.
Zitat:
Die ständige, gestelzte und wie ein Ritus sich selbst auferlegte “Tagesreflexionsprogramm” ist meines Erachtens nicht förderlich. Überspitzt betrachtet ist es genau dasselbe wie das Bart-Simpson-Einhämmerungs-Ritual “Ich werde keinen Zustand testen!” – repetitiv, jedoch nicht kognitiv.
Zitat Ende
Ich kann mir nur ein Szenario vorstellen, in dem Reflexion so ist wie du es schilderst: Man macht jeden Tag das Gleiche und lernt nichts dazu. Ich möche dich damit nicht angreifen. Ich kann mir nur, wie gesagt, keine andere Situation vorstellen.
Was die anderen Aspekte deines Artikels betrifft, schließe ich mich Golo an.
Ach ja, noch etwas: Daß du gerade Ralfs Artikel bezgl Entkopplung von Zuständigkeiten für überflüssug hältst, kann ich auch nicht nachvollziehen. Ich finde es sehr sinnvoll, Objekte die ausschließlich für Tests existieren, aus dem Produktivecode fern zu halten, weil das Verfahren Verwirrungen vermedet. Ralfs Lösung finde ich sehr gut und ich werde sie umsetzen.
http://ralfw.blogspot.com/2009/11/zustand-als-abhangigkeit-ioc-konsequent.html
Hi Rainer,
Ich halte Ralfs Beitrag nicht für überflüssig. Ich denke nur dass er in diesem einen Beitrag sich etwas zu kompliziert artikuliert hat. Ich denke auch, dass er sich selbst mit dem Beispiel des KataPotter keinen Gefallen getan hat, weil er damit sein eigentliches Ziel – nämlich die Darstellung der Vorteile von Interaktionstests gegenüber Statustests – unnötiger Weise unscharf gezeichnet hat.
Im Übrigen finde ich Interaktionstests auch eleganter und besser als Statustests ( http://nat.truemesh.com/archives/000356.html und http://www.martinfowler.com/articles/mocksArentStubs.html), womit ich Dir zustimme und auch “Ralfs Lösung” sehr gut finde und auch schon umsetze.
Ich gebe Dir noch als Anregung mit, dass jeder, der TDD wirklich einsetzt, früher oder später zum Schluss kommen wird, dass es beide Arten des Testens (also Interaktions- und Statustests) geben muss.
Um es in Ralfs Worten zu sagen: Der Zustand ist eine Abhängigkeit, der wenn möglich auch über den “Wartungskonstruktor” injiziert wird, um so isoliert und zielgerichtet Funktionseinheiten in das Zentrum des Zielkreuzes von Tests zu rücken. An den Endpunkten eines Dataflusses, also in der Präsentationsschicht, in der Entitäten erfasst werden, oder aber auch in der Datenzugriffsschicht, in der die Domäne Entitäten und Zustand persistiert, ist der Zustand als Abhängigkeit einer physischen Grenze erlegen. Unter anderem ist es dieser Grenzbereich, der statusbehaftetes Testen in notwendigstem Maße rechtfertigt.
Gruß,
Ilker
Hallo, Ilker!
Wir sind uns in der grundlegenden Sache einig: automatisiertes Testen ist wichtig, und TDD ist noch besser.
Schade finde ich es daher, dass du zwischen nützlichen und hinderlichen Beiträgen zu TDD unterscheidest, die diese Grundlage nicht in Frage stellen.
Du hast deinen Weg zu TDD gefunden. Nach einem Lernprozess bist du nun auf einem Level “bewusster Kompetenz” angelang. Das ist toll. Und du gibst dein Wissen weiter. Noch besser. Jetzt erscheint die TDD einfach, natürlich, unverzichtbar, naheliegend. Super.
Aber dein Lernprozess ist nur deiner. Andere haben ihren eigenen. Und wenn du schreibst, du würdest das Zustandstestpattern, das ich neulich beschrieben habe, “schon umsetzen”, dann bedeutet das ja, dass auch du immer noch etwas lernst. Warum wetterst du also dagegen, dass z.B. Golo oder ich aus unseren Lernprozessen berichten? Warum ist das “Tamtam”?
Dass wir nicht in der Weise berichten, wie du es tust, liegt ja daran, dass wir anders sind. Und die Leser deiner und unserer Blogs sind wieder anders. Ist es da nicht gut, verschiedene Sichten zu bieten? Dann ist für jeden etwas dabei. Manche mögen deinen Stil, manche Golos, manche meinen. Die Welt ist bunt.
“Tamtam”, “Trara”, “fesselnde Trapezschwünge” empfinde ich als unnötig wertende, ja, abwertende Beschreibungen unserer Beiträge. Dass wir nicht immer einer Meinung sind, ist eine Sache. Muss ja auch nicht sein. Aus dem “Aufeinanderprall” unterschiedlicher Meinungen zu einer Sache, entsteht letztlich das Neue, Bessere.
Aber dann fände ich es hilfreicher, wenn du konkret auf Aussagen bezug nähmest. An einem Punkt höre ich da etwas bei dir heraus: “Ich denke auch, dass [Ralf] sich selbst mit dem Beispiel des KataPotter keinen Gefallen getan hat, weil er damit sein eigentliches Ziel – nämlich die Darstellung der Vorteile von Interaktionstests gegenüber Statustests – unnötiger Weise unscharf gezeichnet hat.”
Darüber können wir natürlich diskutieren. Da steckt keine Abwertung drin, sondern sachliche Kritik. Nun kann ich überlegen, ob ich es auch so sehe. Hm… Wollte ich die Vorteile von Interaktionstests gegenüber Statustests zeigen? Nein, das wollte ich nicht. Insofern glaube ich auch nicht, dass ich etwas unscharf gezeichnet habe.
Mit ging es im Gegenteil ausschließlich um Statustests. Ja, wie überprüfe ich den Zustand eines SUT, wenn es keinen Zugriff darauf bietet? Dafür habe ich ein Pattern vorgestellt. Ist das dann gleich “Tamtam”?
Habe ich mir mit der KataPotter keinen Gefallen getan? Das wäre nur der Fall, glaube ich, wenn darin nicht wirklich Zustand vorkäme. Tut es in meiner Lösung auch nicht – aber eben in typischen Lösungen, die ich immer wieder sehe, wenn ich die Aufgabe stelle. Deshalb, weil es so typisch ist, habe ich den typischen Fall herausgegriffen – und weil die Katas grad en vogue sind.
In Summe folge ich also – nach einiger Überlegung – deiner Kritik nicht. Dass du sie geäußert hast, finde ich aber völlig ok. Kein Problem. Nur “Tamtam” und “Trara” schmecken mir nicht.
Noch kurz zu “TDD ist keine Wissenschaft”: Damit hast du natürlich Recht. Eigentlich ;-) Auch Scrum ist keine Wissenschaft. Auch die CCD-Bausteine sind keine Wissenschaft.
Ist es dann aber nicht merkwürdig, dass soviele Entwickler soviele Schwierigkeiten damit haben, all das in ihre Projekte zu übernehmen?
Zurecht zu sagen “TDD ist keine Wissenschaft” hilft einfach nicht. Auch Fahrradfahren ist keine Wissenschaft. Einem Kind zu sagen, “Stell dich nicht an, dafür musst du nicht studieren.” bringt das Kind aber nicht wirklich weiter. Es muss das Fahrradfahren lernen. Auf seine Weise. Aber gern mit angemessenen Tipps und Tricks von erfahrenen Fahrradfahrern.
So ist es auch mit TDD und vielem anderen. Am Ende ist jeder allein beim Lernen – Wissenschaft hin oder her. Aber Lernen ist Veränderung. Und Veränderung ist umso schwerer, je größer Projektdruck oder geringer die Selbstlernfähigkeit. Menschen sind da ganz anders. Unternehmensmilieus sind da ganz verschieden.
Deshalb braucht es Hilfe beim Lernen. Das merken Stefan Lieser und ich in jedem Clean Code Developer Training. TDD vorstellen dauert nicht so lange. Aber TDD einüben braucht viel Zeit bei jedem Teilnehmer. Da müssen eingefahrene Gewohnheiten überwunden werden. Und da hilft dann auch die Reflexion, die dir so überflüssig erscheint.
Über TDD zu schreiben, finde ich daher wichtig. In einer der nächsten dotnetpro Ausgaben wird deshalb auch nochmal ein TDD-Einführungsartikel erscheinen – aus Anlass von ganz konkreten Problemen beim Einstieg in TDD. Warum sollen andere nicht aus den Problemen, die jemand hat, lernen? Die sind wenigstens in der Praxis entstanden, während man den Katas durchaus anlasten kann, dass sie “künstliche Probleme” sind.
In diesem Sinne: Lass uns – jeder auf unsere Weise – die Sache TDD voran treiben.
-Ralf
Morgen Ralf!
“Wir sind uns in der grundlegenden Sache einig: automatisiertes Testen ist wichtig, und TDD ist noch besser.” -> Ich gebe Dir vollkommen Recht.
Nun, dass jeder seinen eigenen Lernprozess hat ist unumstritten. Ich habe meinen, und alle anderen haben auch einen. Ich bin mir der unterschiedlichen Niveaus, Geschwindigkeiten und Herangehensweisen durchaus bewußt.
Aus Deinem Kommentar lese ich eine gekränkte Auffassung gegenüber meiner Zirkus-Metapher, die ich symbolisch für die unnötige Überzeichnung von Sachverhalten herangenommen habe. Wenn ich Dich damit verletzt haben sollte, dann tut mir das Leid. Ich möchte, dass Du erkennst dass das nicht meine Intention war. Ich gönne jedem seinen Schreibstil, genau in dem selben Maße wie Du jedem seine Meinung gönnst.
Dennoch finde ich meine Metapher treffend. Sogar “Trara” und “Tamtam” möchte ich hier stehen lassen. Es soll klarstellen, dass ich *generell* künstlich verkomplizierte Kommunikation (verbal und nonverbal) für den eigentlichen Transport der Information hinderlich finde. Der eben geschriebene Satz zum Beispiel ist künstlich komplex. Genau das selbe (nicht *ab*wertend, sondern *be*wertend) könnte ich auch so schreiben: “Man kann auch einfache Sachverhalte ohne unnötigen Trara und Tamtam rüberbringen”. Ist doch ok, oder was meinst Du? Klar ist es ein stückweit eine Kritik. Aber darum geht es ja. Ich möchte *konstruktive* und *wertschätzende* Kritik an *generell* künstlich verkomplizierter Kommunikation üben. Wenn das nicht so rübergekommen ist, dann hoffentlich jetzt.
Du kommentierst weiterhin (über Deine Intention Deines Beitrags):
“Ja, wie überprüfe ich den Zustand eines SUT, wenn es keinen Zugriff darauf bietet? Dafür habe ich ein Pattern vorgestellt.”
Nun, aus meiner Perspektive reduziert sich das auf die Testmethodik. Ob Du nun einen Interaktionstest machst (also das von Dir sog. “Zustandstestpattern”) oder einen Statustest, kann man Abhängig von der gegebenen Situation entscheiden. Ohne *abwertend*, aber bestimmt *bewertend* zu wirken: Ich verstehe den Beitrag “Zustand als Abhängigkeit” als eine Heranleitung zum Interaktionstest, weg vom Zustandstest. Zitat: “Vermeiden Sie, spezielle Zugriffsmethoden für Zustand nur zum Zweck des Testens einzurichten. Allemal, wenn sie sie nicht wirklich isoliert testen können.” Was ja schon mal prinzipiell gut ist. Doch ich verstehe das als eine Gegenüberstellung von Interaktionstests vs. Statustests. Noch deutlicher wird es, wenn man andere Beiträge zum Thema “Interaktionstest vs. Statustest” liest und vergleicht, z.B. den Klassiker von Miller (http://codebetter.com/blogs/jeremy.miller/articles/129544.aspx).
Zu “TDD != Wissenschaft” meinst Du:
“Ist es dann aber nicht merkwürdig, dass soviele Entwickler soviele Schwierigkeiten damit haben, all das in ihre Projekte zu übernehmen?”
Nein ist es nicht. Denn viele Entwickler sind noch festgefahren oder aber festgebunden. Es ist vergleichbar mit Scrum, da gebe ich Dir Recht. Ich möchte – wiederum nicht *abwertend* sondern *bewertend* als Beipiel eine Aussage von Golo nehmen:
Golo zum Thema TDD != Wissenschaft:
“Ich (ich ganz persönlich) möchte mir Arbeit nur sehr ungerne öfter als ein Mal aufhalsen. Deshalb möchte ich vorher (!) wissen, worauf ich mich einlasse und mir vorher (!) ein durchdachtes Konzept erarbeiten, an dem ich mich orientieren kann.”
Würde man z.B. diese Aussage aus dem Kontext von TDD rausnehmen und in den Kontext von Scrum stecken, dann wäre schnell großes Aufsehen. Denn in den agilen Methoden (sei es Managementmethode oder Softwareentwicklungsmethode) wird genau mit vielen Mitteln versucht, solche Ansichten zu vermeiden. Es heisst “Embrace Change”, methodisch gesehen. Es heisst “Refactoring”, technisch gesehen. Beide Male geht es darum, darüber nachzudenken, wie man die Dinge angehen möchte. Und beide Male geht es darum, *kein* “durchdachtes” Konzept *vorher* zu haben.
Es macht keinen Sinn von einem Extrem (alles durchdenken und analysieren und konzipieren und klarstellen) in das andere Extrem (drauf loslegen, keine Ahnung von den Anforderungen haben, nicht testen) zu schwenken. Agilität, methodisch und technisch, möchte uns meiner Meinung nach eine Richtschnur zur Mitte geben. TDD ist da ein sehr schönes Beispiel. Nicht einfach draufloslegen – aber eben auch nicht in Details vertiefen und verzetteln.
Abschließend:
“In diesem Sinne: Lass uns – jeder auf unsere Weise – die Sache TDD voran treiben.”
Gerne! Ich freue mich auf Deine weiteren Posts und Erkenntnisse. Ich freue mich auf die Coding Dojo’s. Ich freue mich auf Erfahrungsberichte und Meinungen. Ich werde versuchen, meinen Beitrag zu leisten.
Hallo, Ilker!
Bin ich gekränkt gewesen wegen “Trara” und “Tamtam”? Hm… vielleicht ein wenig. Mehr noch aber hat mich gestört, dass ich nicht mal verstanden habe, was du mit “Trara” und “Tamtam” überhaupt kritisiert hast. Ich habe bei dir kein Beispiel gesehen, wo du konkret benannt hättest, was denn das Zuviel an Golos und/oder meinen Ausführungen war. Dass wir überhaupt etwas gesagt haben? Dass wir die für dich falsche Terminologie benutzt haben? Dass wir ein unerhebliches Thema behandelt haben? Ich verstehe nicht, worauf du deine Kritik beziehst.
Und jetzt noch zum Zustandstestpattern: Du schreibst “Ich verstehe den Beitrag “Zustand als Abhängigkeit” als eine Heranleitung zum Interaktionstest, weg vom Zustandstest.” Und ich sage wieder: Nein. Ich will nicht auf den Interaktionstest hinleiten. Ich will eine Form von Zustandstest zeigen. Deshalb finde ich das auch gar nicht umständlich, sondern sehr direkt.
Der Unterschied zwischen beiden ist doch klar: Beim Zustandstest teste ich den Zustand. Haha. Das ist offensichtlich ;-) Wenn ich eine Methode auf Objekt x aufrufe und anschließend schaue, ob der Zustand von x wie gewünscht ist, dann ist das ein Zustandstest. Oder nicht? Genau das kann man mit dem Pattern, das ich dargestellt habe, machen.
Bei einem Interaktionstest befrage ich eben nicht den Zustand. Ich prüfe hingegen, wenn SUT x auf object y zugreift, ob an y die erwarteten Parameter übergeben wurden und das von y zurückgelieferte Resultat korrekt verarbeitet wurde. Und ich prüfe, ob y überhaupt aufgerufen wurde. Sowas findest du aber in meinem Posting nicht. Dazu will ich auch keine Hilfestellung geben. Ich verstehe leider nicht, wie du das also bei mir rauslesen kannst.
Einerlei.
Wir wollen dasselbe erreichen. Ist doch schön ;-)
-Ralf
[...] meine Perspektive eines Coding Dojo’s) schon angedeutet, dass ich mich gerade mit dem Thema TDD & Planung noch deutlich sowie ausführlich äußern möchte und werde. Zurück zur [...]
Ihre Meinung ist gefragt!
Archiv
Diskussionen
Meta
Auszeichnungen
Copyright Ilker Cetinkaya using CC BY-NC-SA 3.0 DE | Powered by WordPress | Log in | Artikel (RSS) | Kommentare (RSS) | Styled with gmblue v0.1 (the next arthemia)