Gedanken zum Test Driven Development (TDD)

Zugriffe: 9547 starstarstarstarstarstarstarstarstarstar Bewertung:2,8 (10 Bewertungen) 27.03.2010

Am 25.03.2010 hat die Franken-.NET-Usergroup das Thema TDD auf der Tagesordnung gehabt. Grund genug, sich auf den Weg von Regensburg nach Erlangen zu machen.

Mein Fazit ist jedoch relativ nüchtern ausgefallen. Doch der Reihe nach. TDD gehört inzwischen zum guten Ton unter Softwareentwickler, genauso wie CCD und OOP/OOD. Doch bringt mich TDD wirklich weiter? Bin ich wirklich effektiver am Ende?

Hier habe ich nach dem Vortrag meine Bedenken. So war eine Aussage: „Ohne ReSharper geht’s gleich gar nicht“ Hallo? Habe ich was verpasst? Es kann ja wohl nicht allen Ernstens davon abhängen, dass ich ReSharper einsetzen muss, um gescheit zu entwickeln! Deutlich ist dann auch geworden, dass in der Tat ein Refactoring der implementierten Codezeile vom Vortragenden fast ausschließlich auf „Anraten“ des ReSharper erfolgte. Irgendwie erinnert das Ganze mich an den immer noch andauernden Handy-Wahn. Fast kein Mensch ist heute noch ohne Handy unterwegs, man muss immer erreichbar sein, die wenigsten schaffen es, das Telefon auszuschalten. Mit dem Re-Sharper scheint ein ähnliches Phänomen bei den Softwareentwicklern angekommen zu sein. Um es gleich deutlich zu machen – ReSharper ist sicher ein sehr gutes Programm, dass seine Dienste tut – aber wenn ich dann nur noch offensichtlich in der Lage bin, Code gescheit aufzuräumen, wenn Fremdsoftware mich dabei unterstützt, dann finde ich es schon etwas traurig, wohin die Entwicklung geht. Doch damit nicht genug – komme ich zurück zum TDD und die Eingangs gestellt Frage: bin ich wirklich produktiver? Jan Welker erklärte gleich zu Beginn des Vortrages, dass ihnen bei der Vorbereitung aufgefallen ist, dass sie nach einer Stunde intensives „coden“ nicht einmal F5 gedrückt haben – sicher fein, aber wie oft haben sie ihre Test gestartet?? Der Abend schaffte Klarheit – überspitzt formuliert: für jede Zeile Code ein Teststart (analog F5). Im anschließenden Gespräch räumte Jan ein, dass man in der Tat wesentlich öfter die Tests startet, als man es sonst mit dem beherzten Tastenanschlag der F5 Taste täte. Na prima, bleibt das Denken nun auf der Strecke?

Ist es denn nicht so, dass ich mir vorher Gedanken mache, was ich für mein Programm implementieren möchte? Tests helfen mir in der Regel, wenn ich mein Programm erweitere und durch meinen Testlauf sicher gestellt werden kann, dass bestehender Programmcode noch weiter funktioniert. Aber eigentlich ja auch wieder der falsche Ansatz, weil dann würde ich im Code erweitern und nicht wie in der TDD vorgesehen, von der bestehenden Testmethode aus, also testgetrieben. Aber brauche ich einen selbst kreierten Kontrolleur meiner Arbeit? Sinnvoll ist das TDD doch erst dann, wenn die Testmethoden von einem Dritten erstellt werden und nicht vom Programmierer selbst. Wenn der Entwickler den Test formuliert, dann sehe ich auch hier die Gefahr, dass die Tests nur soweit formuliert werden, wie das Verständnis des Programmierers für die geforderten Funktionalitäten am Ende sind. TDD soll mich dazu anhalten, nur das zu implementieren, was auch tatsächlich benötigt wird – aber mal ganz ketzerisch gefragt: machen wir das nicht immer?? Jetzt steht auf der anderen Seite CCD mit seinem „Anspruch“, dass wir gut sortiert und aufgeräumten Code schreiben, der auch noch nach Wochen lesbar und verständlich ist. Das gleiche Ziel verfolgt aber TDD auch -> YAGNI.

Im Rahmen des Treffens kamen dann noch Fragen auf, ob man nicht auch „private“ Methoden Unit-Tests unterziehen kann. Das Ganze entwickelte sich dann plötzlich in eine weitere überraschende Richtung, in dem Tom den Einwand erhob, doch bitte nur gegen Interfaces zu programmieren und nur das, was öffentlich bekannt sein soll, eben über ein Interface bereit zu stellen. Oh je, dachte ich so bei mir. Also private Methoden muss ich nicht separaten Tests unterziehen, denn der Ansatz der TDD ist ja gerade, dass ich von einer Methode her implementiere, teste und dann aufräume. Im Zuge des Aufräumens entstehen meine privaten Methoden. Da der Test vorher gelaufen ist, brauch ich also die neu entstandenen Methoden eben nicht mehr separaten Tests unterziehen.

Die Frage, die sich mir nun stellt ist, wie geht es weiter? Der derzeitige Status Quo ist für mich etwas verwirrend. Was mir fehlte an diesem Abend ist die Testautomation mit Visual Studio. Ich verstehe nicht, warum ich nicht die Testmöglichkeiten des Studios nehme. Gut, einzig das Argument, dass Tests im Studio erst mit der Professional-Version von Haus aus möglich sind, würde die Vorgehensweise, wie sie am Abend besprochen wurde rechtfertigen.

Die meisten Probleme, die in der Entwicklung auftreten, betreffen in der Regel Fragen des Integrationstest. Ich persönlich sehe nicht die Probleme in der Entwicklung, dass ich mich von TDD abhängig mache. Sicher ist die Vorgehensweise, vom Test zum Code zu entwickeln, von Vorteil – doch sehe ich darin kein Allheilmittel. Fragen des Integrationstest, Fragen des Tests von mit einander verbandelten Komponenten sind offen geblieben.


15 Kommentare
Gregor Biswanger Gregor Biswanger Sonntag, 28. März 2010

Hallo René,

erst mal Klasse das Du öffentlich über deine Erfahrung und Meinung sprichst. Ich selbst habe bereits zahlreiche Projekte mit TDD & BDD betrieben und kenne somit die ersten Stolpersteine auf den erfolgreichen Weg!

Zu deinem ersten Punkt mit „TDD sei nur mit ReSharper“ sauber ausführbar, möchte ich hiermit widerlegen. Erstens wird durch ReSharper nur ein weiteres Intellicense angeboten, das von Visual Studio bei nicht vorhandenen Klassen auslässt. Die Klassen können auch mittels [Strg] + [ . ] auch von Visual Studio erzeugt werden. Außerdem wird ab Visual Studio 2010 TDD verstärkt unterstützt. Es ist sogar ausgereifter als wie mit ReSharper. VS2010 kann somit auch neue Projekte automatisch anlegen, und somit kann man neue Klassen besser in Schichten aufteilen. Ich habe bereits darüber gebloggt gehabt: http://www.dotnet-blog.net/post/2009/05/08/Meine-Schatze-ReSharper-und-Visual-Studio-2010.aspx.

Dann zum nächsten Punkt, das wäre die Ersparnis der Taste [F5]. Dieser ersparte Weg ist auch eines der bedeutendsten Vorteile von TDD! Denn erstens wird hier vereinfacht ein Reverse Engineering möglich. Das Dich somit auf komponenten-orientiertes Programmieren zum richtigen und sauberen Ziel führt. Nicht nur das, sondern durch das stätige Ausführen der Anwendung im Debugg-Modus, wird eine manuelle Eingabe der Daten erwartet, die Dich dann zu deiner neuen Funktion führen sollen. Nun kann es sein, das Du im Hintergrund irgendwelche ungewollten Nebeneffekte deiner neuen Funktion gar nicht mehr bemerkst. TDD kann Dir genau sagen, welche Funktionen nun beeinflusst wurden. Bis dahin, dass man sich als Entwickler auch gerne vertippen kann.

Dein dritter Gedanke ist eines der größten Probleme für TDD Einsteiger! Ich würde es als „Angst vor TDD“ bezeichnen. Diese Angst lässt auch für viele Menschen einige Ausreden einfallen, weshalb Sie TDD nicht einsetzen können. Denn es fehlt am Gefühl, wie die Implementierung dahinter überhaupt aussehen soll. Dazu hab ich bereits persönlich mit Ralph Westphal philosophiert und wir beide arbeiten auf die gleiche Art und Weise. Wenn uns das Gefühl zur späteren Implementierung fehlt, entwickeln wir vorerst eine Art Prototyp (bezeichnet als Experimentelles Prototyping). Somit bekommt man das Gefühl zur späteren Implementierung und deren Architektur.

Dann zu deinen Gedanken mit den „private“-Methoden. Hierbei möchte ich Deine denkensweise als korrekt bestätigen. Sobald die „public“-Methode, Ihren Zweck erfüllt hat, dass der Test grün ist, ist das gerechtfertigt. Ich selbst hatte ein Projekt, wobei die Entwickler in Indien saßen. Wir Architekten haben dann Schritt für Schritt mit TDD die Vorgaben gemacht. Alles was die Inder „private“ gemacht haben, hat uns nicht „ernsthaft“ interessiert. Sobald Sie für „public“ die saubere Arbeit abgegeben haben ;)

Gemeinsam mit Robert Walter war ich auf „TDD & BDD“ User Group Tour (http://www.dotnet-blog.net/post/2009/05/13/Test-Driven-Development-Behavior-Driven-Development-Roadshow.aspx). Wenn Ihr Interesse habt, können wir gerne das Thema nochmal genauestens mit euch durchgehen. Auch für weitere Fragen stehe ich Dir gerne zur Verfügung.

Beste Grüße aus Ingolstadt,
Gregor

Christian Pappert Christian Pappert Sonntag, 28. März 2010
Hallo Renè,

also für mich liegen die Vorteile darin, dass ich für einen kurzen Test nicht die gesamte UI starten muss und das ich auch im nach hinein gewünschte Verhaltensweisen in einem Rutsch testen kann ohne die gesamte UI mit einem manuellen Test zu prüfen, zu mal die innere Struktur meiner Anwendungen weitaus komplexer ist als die UI hergibt. Bevor man darüber urteilt, sollte man es intensiv ausprobiert haben, aber vielleicht habe ich Dich hier auch falsch verstanden.
Vom ReSharper kann man einiges lernen, selbst wenn man jahrelang mit C# oder VB entwickelt und Bücher wie "Expertenwissen zu CLR" von Jeffrey Richter gelesen hat. Es gibt kein Tool, auch das neue VS 2010 mit dem man so schnell und sicher Refactoring betreiben kann. Und es nimmt einem die Arbeit ab, nicht das denken.

Viele Grüße,
Christian
Ilker Cetinkaya Ilker Cetinkaya Sonntag, 28. März 2010
Schade. Wirklich schade, das Jan und Jürgen Dich nicht überzeugen konnten. Denn TDD kein reines "Testwerkzeug". Es geht um das Design der Software, die Du entwickelst. TDD = Test Driven Design. Und genau so, wie Design Patterns oder UML oder CCD oder SOLID oder F# oder NHibernate oder Google kein Allheilmittel ist, ist auch TDD kein Allheilmittel. TDD ist ein Werkzeug, um das Software-Design zu gestalten und dabei auch noch die Anforderungen an die Software zu dokumentieren.
Thomas Thomas Sonntag, 28. März 2010
Hallo René,

Mist, da hätte ich wohl am Donnerstag doch mal vorbei kommen sollen. Was ich da bei dir rauslese ist die Skepsis des Programmierers, der seit Jahren dabei ist und "das immer schon so gemacht hat".

Ging mir auch so. Aber ich fand die Argumentation pro TDD irgendwann so überzeugend, dass ich mal ein komplettes, kleineres, Projekt testgetrieben entwickelt habe. Am Ende standen dann nach 6 Wochen Projektlaufzeit 2 Anfangswochen, in denen es sehr holprig lief, auch weil ich mich mehr mit der richtigen Arbeitsweise beschäftigen musste (Mocken z.B.), 4 Wochen testgetriebene Entwicklung mit insgesamt über 400 Tests und schlussendlich eine Software, die bis heute fast fehlerfrei gelaufen ist. Ich habe vorher selten etwas ausgeliefert, was aus dem Stand so wenige Bugs enthielt.

Zu ReSharper:

Es ist nun mal leider so, dass ReSharper gerade für das Refactoring Möglichkeiten innerhalb der IDE eröffnet, die es ohne nicht oder nur eingeschränkt gibt. Daher gehört es auch für mich zur Grundvoraussetzung für jeden Entwicklerarbeitsplatz. Sich darüber zu echauffieren bringt niemanden weiter. Genauso gut kann man auch pro Notepad und contra Visual Studio argumentieren.

Zur Testautomation in VS:

Es spricht nichts dagegen nur auf VS zu setzen. Die 400 oben genannten Tests habe ich genau so, also mit dem eingebauten MS Test, erstellt. Inzwischen setze ich auf nunit, aber nur, weil mir das mit dem Testrunner von ReSharper ein paar schönere Ausgabemöglichkeiten bietet (Beispiel: http://twitpic.com/194qrp)

Zu TDD vs. CCD:

TDD führt automatisch zur cleanerem Code, ist also auch selbstredend eine Bestandteil von CCD. Dadurch, dass du bei der testgetriebenen Entwicklung, also test-first (red, green, refactor) dazu gezwungen wirst, dir genaue Gedanken über die Unit, also meist Methode, zu machen, und diese Gedanken in Tests zu fassen, zwingst du dich selbst dazu, nur das zu implementieren, was wirklich gebraucht wird (YAGNI). Außerdem erliegst du nicht mehr der Versuchung, Sachen mehrfach zu implentieren, da du sie so auch mehrfach testen müsstest (DRY).

Zu Toms Aussage und privaten Methoden:

Er hat Recht. Darauf kommst du zwangsläufig, wenn du testgetrieben entwickelst. Denn du wirst mocken, faken usw. müssen. Eine Geschäftsmethode, die mit Daten arbeitet, wirst du nicht damit testen, dass sie diese Daten live aus einer Datenbank holt. Also musst du die Quelle mocken, z.B. mit RhinoMocks. Um das zu gewährleisten, musst du gegen Interfaces arbeiten.

Zum testen privater Methoden: es ist im Prinzip ganz einfach. In dem Moment, wo du öffentliche Methoden testest, testest du auch die privaten mit. Denn diese werden von den öffentlichen aufgerufen - ist der Test erfolgreich, ist auch die private Methode, die ja etwas tut, was du im Test erwartest, in Ordnung.

Fazit:

Spring über deinen Schatten, leg deine Skepsis ab und gib TDD/BDD eine Chance. Es wird sich lohnen. Nicht in jedem einzelnen Fall, nicht in jedem Projekt, aber im Großen und Ganzen.

Es ist eine enorme Umstellung, aber eine lohnenswerte. Man erzeugt natürlich einen Wasserkopf, und nach dem ersten Projekt wirst du auch nicht mit deinen Tests zufrieden sein. Also wirst du im darauf folgenden Projekt deine Arbeitsweise wieder etwas anpassen und so wieder mehr Aufwand und weniger Produktivität sehen. Aber sobald du deinen Weg gefunden hast, bzw. das Team, und das Ganze rollt, ist TDD/BDD sehr lohnenswert.

Ich möchte komplexere Anwendungen jedenfalls nicht mehr ohne entwickeln.
Bernd Hengelein Bernd Hengelein Sonntag, 28. März 2010
Hallo René,
ein zweistündiger "Vortrag" bzw. Live Coding kann natürlich nicht alle Fragen zu TDD und alle Zweifel ausräumen. Ich denke auch, dass ein wichtiger Punkt ist (wie Ilker auch schon angemerkt hat), dass es bei TDD eigentlich nicht ums Testen im Sinne von Fehler finden geht. Vielmehr ist TDD das Werkzeug des Entwicklers um Fehler schon im Vorfeld zu verhindern. Und mit diesem Sicherheitsnetz kann relativ gefahrlos Refaktoring betrieben werden. Ich vermute auch, dass Deine Enttäuschung vielleicht auch ein bisschen daher kommmt, dass Du mit einer anderern Erwartungshaltung zu dem Treffen gekommen bist (das schliesse ich aus den Fragen, die Du im Vorfeld an die Vortragenden hattest). Um bestehenden "Legacy Code" Stück für Stück under Test zu bringen, empfehle ich wirklich das Buch "Working Effectively with Legacy Code" von Michael Feathers. Um TDD umzusetzen bedarf es einer ordentlichen Portion Geduld und Ausdauer. Man muss lernen gute, gut wartbare Test zu schreiben, seine komplette Arbeitsweise umstellen usw. Um mich meinen Vorkommentatoren anzuschliessen: Es lohnt sich!
Viele Grüße,
Bernd
Rene Drescher-Hackel Rene Drescher-Hackel Sonntag, 28. März 2010
Ich möchte mal zu einigen Kommentaren etwas näher nochmal eingehen:

Prinzipiell bin ich vom Ansatz der TDD überzeugt. Es ist keine Frage, dass in der TDD diverse Vorteile stecken. Wie die Test und vorallem der Start in die TDD vorangetrieben werde kann/sollte, das ist mir an diesem Abend etwas zu kurz gekommen.
So hatte ich Jan im Vorfeld einen konkreten Problemfall geschildert, wo ich schon mir eine Antwort erwartet hätte. Das Gespräch mit Jan hat dann aber gezeigt, dass die Problemstellung nicht klar wurde. Es ging nicht darum bestehende Software testfähig zu machen, sondern um die Problematik, wie man testgetriebene Entwicklung bei eng verbandelter Komponeten vorantreibt - ganz nach dem Henne-Ei-Problem. So war es ein Abend an der Oberfläche von TDD. Fragen der Integrationstest blieben unbeantwortet. Schade eigentlich.

TDD ist sicher kein Tool oder dergleichen - es ist ein Weg, der die Art der Softwareentwicklung prägen wird und sollte. Aber wie Gregor es aus einem eigenen Projekt schon in seinem Kommentar geschildert hatte: Test sollten immer vom Architekten der vorgegeben werden. Der Entwickler (die Arbeitsbine also ;-) ) setzt die Software anhand des Tests um. So ist letztlich sichergestellt, dass die Software so funktioniert, wie der Architekt die Anforderung auch umgesetzt hat. Das ist meines Erachtens auch der tiefere Sinn der TDD.

Zum Resharper: Ich sagte ja klar, dass es ein sehr gutes Tool ist, dass seine Dienste tut. Ich verstehe nur nicht, wie man die Auffassung vertreten kann, dass ein vernünftiges Testen ohne Resharper nicht wirklich ginge. Nun, da sind wir wieder beim Handy: es ging vorher auch ohne - oder? Man sollte immer auch in der Lage sein, die Arbeit, die Resharper dem Entwickler abnimmt, auf den Prüfstand stellen zu können.
Was macht der Autofahrer, der mit Navi unterwegs ist? Es gab schon Kandidaten, die sind prompt in den Fluss gefahren, weil das Navi nicht mitgeteilt hat, dass die Strasse gleich zu Ende ist. Diese Problematik sehe ich irgendwie, wenn man sich so "blind" auf Fremdsoftware verlässt.
Es ist keine Frage für mich, dass Resharper eine gute Unterstützung bei der Arbeit liefert. Ich überlege genau aus diesem Grund, mir eine Lizenz anzuschaffen - mal abwarten.

Weiter hätte ich mit datailierte Ausführungen zum Mocken erhofft. Das ist doch auch eher der Regelfall in der Entwicklung, dass ich voneinander abhängige Komponenten im Einsatz haben -> zB. BusnessKomponente->DatenbankLayer.

TDD ist aber auch ein Thema, dass nicht nur im Kopf des Entwicklers klar sein muss, sondern im ganzen Team, in der Firma bis hin zu den Entscheidungsträgern. TDD ist nur sinnvoll umzusetzen, wenn alle im Unternehmen am gleichen Strang ziehen.

Wir werden das Angebot von Gregor sicher noch mal aufgreifen und den Einsatz von TDD in der Firma auf jeden Fall weiter vorantreiben. Wie wichtig TDD im Softwareentwickleralltag ist, hab ich zur genüge in verschiedenen Firmen live erleben können.
Gregor Biswanger Gregor Biswanger Sonntag, 28. März 2010
Hallo René,

das Praxisbeispiel von mir, sollte nur zeigen, dass dies auch ein sehr gutes Werkzeug für Architekten ist (Bezeichnet als Design-by-contract). Aber TDD ist kein Werkzeug, das NUR für dieses Szenario bedacht war. Es wurde vorerst nur eingesetzt um konsequent seine Tests zu schreiben. Denn nach der Implementierung hat der Entwickler meißt kein Interesse an weiteren Tests zu schreiben. Viel eher ist er an der nächsten Implementierung von Funktionalitäten fixiert. Das allerdings das "test-first" solche mächtigen Aspekte mitbringt, haben die Erfinder von TDD bestimmt nicht erwartet :) Es lenkt ganz klar, das Software-Design vom Architekten und den Source-Code des Entwicklers. Dabei ist jeder Entwickler auch sein eigener Architekt.

Beste Grüße,
Gregor
Bernd Hengelein Bernd Hengelein Sonntag, 28. März 2010
Hallo René,
dass Fragen der Integrationstests unbeantwortet blieben, lag zum einen daran, dass es um TDD im eigentlichen Sinne ging, was IMHO nichts mit Integrationstests zu tun hat. Und zum anderen daran, dass während des Vortrags keine Fragen dieser Art gestellt wurden.
Wenn Du sagst, dass TDD kein Tool oder dergleichen ist, dann haben wir einfach Grundverschiedene Ansichten zu dem Thema. Bei TDD schreibt weder der Architekt noch der Tester noch irgendjemand anderes als der Entwickler die Tests. Um zu überprüfen, ob Anforderungen korrekt umgesetzt wurden, dienen die Acceptance Tests.

Wie TDD mit Integrationstests und Acceptancetests zusammenspielt (denn TDD kann letzteres ja nicht ersetzen) ist sicherlich etwas, wofür man mehr Zeit als einen Abend benötigt. Da ist wahrscheinlich das Beste, wenn ihr euch in der Firma Unterstützung vor Ort holt, die an euren konkreten Problemen weiterhelfen kann.
Happy TDDing,
Bernd
Ilker Cetinkaya Ilker Cetinkaya Sonntag, 28. März 2010
Hmm, es gibt so vieles, was ich über deine Meinung und die Kommentare sagen wollen würde. Um es jedoch kurz zu halten beschränke ich mich auf die wesentlichen Punkte.

Bernd hat meine volle Unterstützung bzgl. der Umsetzung von TDD bzw. test-first. Keiner außer der Entwickler selbst schreibt die Tests. Wenn ich Code schreibe, schreibe ich die Tests. Ansonsten könnte ich ja kein Code schreiben (-> test-first). Auch der Auffassung, TDD sei kein Werkzeug, muss ich leider vehement entgegentreten. TDD ist aber sowas von ein Werkzeug! Z.B. um Code sauberer und schlanker zu schreiben. Das Beispiel von Thomas ist sehr anschaulich. Gregor merkte ja schon an, das TDD am Anfang nur ein Testwerkzeug war, aber jetzt viel mehr als das ist. Das ist im Prinzip auch richtig. Lass' dich aber bitte durch das T in TDD nicht irritieren. Leider löst das Wort "TEST" in vielen Köpfen eine besonders heftige Assoziation mit Verifikation aus. Das ist aber nicht der Fall, das kann ich Dir versichern. Abschließend nochmal eine Unterstützung des Aufruf's von Thomas: Gib' Dir einen Ruck und TDD eine Chance - es lohnt sich!
Robert Mühsig Robert Mühsig Sonntag, 28. März 2010
Interessante Diskussion - als Gregor letzten Mittwoch bei der .NET UG Dresden zu Gast war hatten wir auch über Unittesting bei einem Bierchen gesprochen :)
Ich kenne in meinem Bereich kein Projekt, welches mit TDD entwickelt wurde, aber ich bin fest der Überzeugung das es irgendwie gehen muss :)
Ein "Kernproblem" was ich noch sehe (und auch viele Kollegen) ist die Wartung der Tests. Wenn sich Anforderungen ändern muss ich doch evtl. auch wieder 5-x Unittests anpassen. Es wird z.B. ein neues Pflichtfeld eingeführt oder der Ablauf ändert sich.
Das kann sich ja unter anderem auf den ein oder anderen Test auswirken, oder?

In einem privaten Projekt haben wir mit TDD angefangen, aber zum Teil ist es aufwändig gewesen alle X-Szenarien mit Unittests zu hinterlegen und wenn sich etwas ändert, dann mussten wir die Mocks auch umstellen. Meistens sieht man in Vorträgen nur die Anfangszeit und da ist alles logisch und schön. Aber der richtige Zeitfresser kommt ja erst, wenn sich Anforderungen ändern.

Eine andere Frage die mich beschäftigt: Wie stellt man sicher, dass alle Daten aus dem Repository geladen werden? Muss ich das Repository testen? Da dort ja ein Datenspeicher mit einbezogen ist, ist es ja schon ein Integrationstest, oder?

Gibt es eine einigermaßen komplexes Webprojekt in .NET, welches mit Unittests ausgestattet ist und Open Source ist? Ich würde gern mal sehen wie man denn seine Unittests gut strukturiert und vielleicht daraus auch erkennen was ich falsch gemacht hab bei meinem privaten Projekt.
Bernd Hengelein Bernd Hengelein Sonntag, 28. März 2010
Hallo Robert,
ich weiss, dass das Code Camp Server Projekt von Jeff Palermo Unittests hat (ich glaube auch TDD entwickelt wurde). Keine Ahnung, wie die Qualität der Tests ist. http://code.google.com/p/codecampserver/
cu,
Bernd
Thomas Thomas Sonntag, 28. März 2010
@René

Ich finde in deinen Aussagen schwingt wieder mal ein ziemlich destruktiver Ton mit, was ich schade finde. Insbesondere was deine enttäuschte Erwartungshaltung angeht, kann ich dich leider wenig verstehen. Wenn dir Informationen gefehlt haben, kannst du sie ja problemlos online oder in Gesprächen mit anderen (Dotnet Cologne?) nachholen.

Zu deinen einzelnen Aussagen:

TDD ist DAS Tool dieser Zeit (Guten Morgen .NET-Welt übrigens, anderswo lacht man über derartige Diskussionen, weil man sie schon fast 10 Jahre hinter sich hat).

Nein, Tests schreibt der Entwickler. Wenn test-getrieben entwickelt wird, geht es gar nicht anders. Im Übrigen kann das jeder im Kleinen für sich selbst tun, es muss nicht das gesamte Team mitziehen. Aber jede Wette: wenn deine eigenen Komponenten sauber und fehlerfrei entwickelt werden, wenn du test-driven entwickelst, wirst du sehr schnell das Interesse der anderen Team-Mitglieder wecken.

Noch mal zu Resharper: Testen geht auch ohne Resharper. Ich weiß nicht, was du da in den falschen Hals bekommen hast oder was beim Vortrag erzählt wurde. Aber Resharper macht vieles leichter, insbesondere beim Refactoring. Dabei muss man sich freilich nicht blind darauf verlassen. Scheint mir hier ein Missverständnis zu sein.

@Robert

Da klingt aber auch die Bequemlichkeit durch :o). Aber du hast Recht, die Wartbarkeit ist ein Thema. Eins, was zwangsläufig in Richtung BDD führt. Ich habe aktuell für mich einen Mittelweg gewählt und das Naming der Tests umgestellt. Ich schreibe zuerst meine Anforderungen in Notepad und setze das dann 1:1 in Testklassen und -Methoden um, so dass ich sehr leicht lesbare Tests bekomme, die sich so auch später noch leicht nachvollziehen lassen (siehe Link in meinem ersten Kommentar).

Die Tests selbst muss man natürlich auch versuchen übersichtlich zu gestalten. Hier gilt noch viel Handarbeit bzw. das Schreiben von ExtensionMethods und Erweiterungen für RhinoMocks. Damit bin ich aber inzwischen ganz zufrieden, wenn ich mir meine ersten Tests anschaue (...) und die mit den heutigen vergleiche, würde ich sagen, dass ich diese Tests in 2 Jahren durchaus noch freiwillig lesen werde, was man von den ersten nicht behaupten kann.

Was das Erweitern anbelangt: klar, wenn du z.B. bei einem MVC-Controller noch nen Konstruktorparameter für einen weiteren Service hinzufügst, musst du auch deine Tests anpassen. Aber ehrlich gesagt sehe ich das nicht als Problem an. Es ist Arbeit, aber keine die irgendwie einen so großen Faktor besitzt, dass man den TDD-Weg nicht wählt. Und eigentlich sollten sich Interfaces ja auch nicht mehr ändern ... ;-)

Grüße
Rene Drescher-Hackel Rene Drescher-Hackel Sonntag, 28. März 2010
Hallo Thomas,

ja klar war ich enttäuscht, was den Abend anging. Aber - um es auch klar zu sagen - ich bin überzeugt davon, dass TDD wichtig, wenn nicht gar ein Muss ist. Mir ging es in diesem Beitrag darum, dass ich die erforderliche Gesamtschau vermisst habe, denn für mein Verständnis gehört zu einer testgetriebenen Entwicklung auch eine Schau auf Integrations- und Akzeptanztest - auch wenn ich möglicherweise mit dieser Ansicht allein da stehe.

Zum ReSharper nochmal: klar erleichtert das Tool die Arbeit, mich hat die Aussage aber gestört, dass es "ohne" eigentlich nicht ginge, was ja genau genommen so nicht richtig ist. Hier hätte ich mir eine andere Demonstration sicher gewünscht.
Viele Unternehmen, die Software entwickeln sind Microsoft-Partner. Was dies wirtschaftlich für diese Unternehmen bedeutet, brauche ich hier nicht zu erklären. Du kannst aber nicht in einem Unternehmen auflaufen und TDD propagieren und gleichzeitig sagen, "wenn wir gescheit arbeiten wollen, dann brauchen wir...". Die Grunderwartung ist: was können wir mit den gegebenen Möglichkeiten tun?

Klar erhoffe ich mir in Köln zu dem Thema noch mehr Informationen zu bekommen. Es ist mit ein Grund, weshalb ich dahin fahre.

Dass der Softwareentwickler die Tests für sich im Kleinen macht, ist eher Wunschdenken bzw. der Idealfall. In den Firmen/Projekten, wo ich bislang tätig war, war dafür kein Platz. Und glaube mir Thomas, irgendwann gewöhnst du es dir ab, mit deinem Projektleiter/Vorgesetzen darüber zu diskutieren - so ist das ebend.
(Im aktuellen Projekt ist eine offene ernste Bereitschaft zu TDD da, was ich Klasse finde.)

Am Abend hatte Tom oder Bernd (so genau weiß ich es nicht mehr, wer es war) wohl nicht ganz grundlos die Frage gestellt: "Wer würde gerne TDD einsetzen und darf es nicht..." Die Reaktionen darauf brauche ich dir sicher nicht näher zu beschreiben.
Ich bin überzeugt davon, dass wenn du testgetrieben entwickeln willst, es nur wirklich sinnvoll ist, wenn im Team alle mitziehen - andernfalls sehe ich es als Kampf gegen Windmühlen. Die gleiche Situation hast mit den Fragen zum CCD.

Zum Schluss noch was anderes - nicht das hier ein falsches Bild vom Ganzen entsteht: ich weiß, dass es viel Arbeit macht, einen Vortrag für ein Usergrouptreffen vorzubereiten und ihn zu halten. Es soll ja auch nicht der Eindruck am Ende hängen bleiben, dass der Vortrag gar schlecht gewesen wäre, das war er keinen Falls - es ist nur, dass ich in der Tat mit bestimmten Erwartungen gekommen war und relativ enttäuscht gegangen war. Für mich persönlich kam, was TDD angeht, nicht viel neues rum.
Christina Hirth Christina Hirth Mittwoch, 31. März 2010
Hallo René, Thomas, Gregor, Bernd, Robert, Ilker,

richtig toll diese Diskussion hier :)

Ich möchte hier Jimmy Nelson zitieren, ich glaube, er hat es hervorragend formuliert:

"TDD sound dull and boring, and developers often expect it to be a pain in the backside. They couldn't be more wrong! In my experience, the opposite is true - it is actually great fun, which came as surprise to me. I guess the reason that is such fun is that you get instant feedback on your changes, and because we are professionals, we enjoy creating high-quality applications.
Another way to put is is that TDD isn't about testing. It's about programming and design. It's about writing simpler, clearer, and more robust code! (Sure the "side-effect" of created unit tests is extremely important!)"

Das ist ein Zitat aus seinem Buch "Applying Domain-Driven Design and Patterns". Das Buch ist in 2006(!) erschienen (wie Thomas sagt: Guten Morgen .NET-Welt ;) )

@René: hier ein paar Tipps, wie du Legacy-Code testbar machen kannst inklusive Tests: http://www.yellow-brick-code.org/?p=25 Wenn die Kapselung stimmt, dann kann jede neue Funktionalität testdriven entwicklet werden.

Gruß
Christina
Ralf Westphal Ralf Westphal Freitag, 2. April 2010

Neuen Kommentar verfassen

Bestätigungscode