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

“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.

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

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

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.

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

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

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