Bezieht man sich bei der testgetriebenen Entwicklung nur auf die blanke Theorie, so bleiben die eigentlichen Vorteile häufig zu abstrakt. Im nachfolgenden Video wird deshalb eine sehr einfache Code Kata gelöst. Auf diese Weise soll gezeigt werden wie produktiv man mit den entsprechenden Werkzeugen arbeiten kann und wie sehr die so entstandene Testabdeckung bei der Refaktoriserung des Quellcodes hilft.
Archiv
Tag: TDDDieses Jahr war ich für Microsoft als Sprecher auf den Testing Info Days unterwegs. Dies waren zwei Veranstaltungen im März, bei denen ich jeweils in München und Hamburg über Unit Testing mit Visual Studio gesprochen habe. Der entsprechende Mitschnitt dazu findet sich auf Channel 9 und kann nachfolgend auch angesehen werden. Leider gab es wohl beim Schnitt ein paar Probleme mit den Folien wodurch diese nach einiger Zeit asynchron angezeigt werden 
Weitere Informationen gibt es auch auf der entsprechenden Webseite von Channel9.
Gestern war ich bei Agile Saxony und habe über die unterschiedlichen Schulen des TDD gesprochen und wie sie sich auf unsere Arbeitsweise auswirken. Für mich besonders interessant war dabei die Diskussion am Ende meines Vortrages. Denn anscheinend war meine Vortragsweise etwas negativ konnotiert, wodurch ich eher skeptisch als überzeugt gewirkt haben muss. Ich war sehr übernächtigt, daher entschuldigung an dieser Stelle, wenn der Vortrag nicht die sonst übliche Qualität hatte. Continue reading “Qualität, aber bitte agil!” »
Ich gebe gern zu, dass ich mich am Anfang eher schwer mit TDD getan habe. Der Grund dafür war, dass die Lehren die ich aus Büchern und Dojos zog, so gar nicht in meinen Entwickleralltag passen wollten. Kleine Umsetzungsschritte die nicht selten durch sinnlos scheinende Zwischenaktionen geprägt waren, haben mich fast zur Weißglut getrieben. Wenn ich dann TDD anwendete verzichtete ich also auf diese Schritte und fand mich nach einiger Zeit wiederum damit konfrontiert, dass meine Tests viel zu komplex wurden und die angeblichen Vorteile von TDD praktisch nicht präsent waren.
Continue reading “„Ausprägungen des TDD“ aka „Die Triangulations-Baby-Step-Holzkeule“” »
„Agilität, Agilität, Agilität.“ So rauscht(e) es durch die Softwareentwicklungslandschaft. Jeder der nicht wenigstens iterativ arbeitet ist uncool, ewig gestrig, arbeitet fernab jeder Realität und wird auf Dauer einen langen und qualvollen Tot in der Change-Request-Refaktorisierungs-Bug-Ping-Pong-Hölle sterben. Na gut, letzteres passiert meiner Erfahrung nach eher denjenigen die sich all zu unvorsichtig auf die Agilität eingelassen haben ohne ihre tatsächlich gelebten Vorgehen einmal in Frage zu stellen.
Die Verschmelzung zweier Welten hat immer zur Folge, dass Teile dieser zwei in die Neue übergehen und das ist völlig richtig so. Dumm nur, wenn Dinge konvergieren die eigentlich besser nicht kombiniert werden sollten. Dann wird aus dem Elysion sehr schnell der Tataros. Genau das passiert meiner Meinung nach wenn sich die Qualitätssicherung nicht daran anpasst, dass Requirements verändert werden. Denn so viel hat das Mantra der Agilität erreicht: In den Köpfen ist angekommen, dass es besser ist auf Veränderung zu reagieren als einem strikten Plan zu folgen. Im Umkehrschluss also: Alles bleibt anders!
Continue reading “Agilität, Qualität & andere Missverständnisse…” »
… and all I got was this lousy Christmas tree.
I like TDD and I like test automation. It is great to see the application growing with each successful test and to be sure that it will work even if a lot of changes are made on the code base. On the other I see (especially) TDD as a practice which is hard to master and I can understand people who drop any ambition because it feels intricate and some times frustrating in real projects.
One of these things is for example the advice to use baby steps to drive the implementation. I thing this advice is essentially to TDD and makes, from my point of view, the difference between Test First and Test Driven Development. Baby steps means, that you are not allowed to implement more functionality than needed by your tests. If the test expects a 1 as return value of your method, than your first step would be to simply return a 1. Your algorithm will also grow with each test you write and that’s why it is called Test Driven Development. This has also the advantage that the your tests get more robust, they are easier to change and to read, at least in theory.
Einer der viel gesprochenen Leitsätze des Testens ist: „Finger weg von privaten Membern“. Der Gedanke hinter dieser Aussage ist einleuchtend, denn je mehr Aussagen ich in einem Test über die Implementierung mache, desto höher die Wahscheinlichkeit, dass ich ihn später anpassen muss oder er fehl schlägt.
Nichts desto trotz, kann man sich durch den Zugriff auf private Member gelegentlich viel Arbeit sparen wenn es darum geht einen Test aufzusetzen und außerdem hilft es manchmal sogar beim Aufspüren von Bugs. Weiterhin ist es teils unumgänglich auch Dinge zu testen die als internal gekennzeichnet sind und demnach theoretisch nicht vom Testprojekt identifiziert werden könnten. Continue reading “How-To: Private und internal testen mit MS Test” »
In einem früheren Post hatte ich einmal beschrieben wie Data-Driven-Tests mit NUnit umgesetzt werden können. Damals habe ich bereits darauf hingewiesen, dass so etwas theoretisch auch mit MS Test und dem Visual Studio möglich ist, was ich nun erläutern möchte.
Continue reading “How-To: Datengetriebene Tests mit MS Test” »
Wie letzte Woche versprochen präsentiere ich heute ein mögliches Ergebnis der Lottery Kata. Dabei werde ich klären was es mit parametrisierten und datengetriebenen Tests auf sich hat, wie man sie mit NUnit umsetzt und welche Vor- bzw. Nachteile sich ergeben können. Die eigentliche Umsetzung der Logik ist nur am Rande interessant und wird größtenteils außen vor gelassen.
Continue reading “„Eine Lösung der Lottery Kata“ aka „Data-Driven-Tests mit NUnit“” »
Coding Dojos erfreuen sich großer Beliebtheit. Kein Wunder, kann man sich dank ihnen doch endlich mal ungezwungen mit dem wirklichen Handwerk unserer Zunft auseinander setzen: Dem Produzieren von Code.
Obwohl es nun schon eine ganze Reihe von Katas (Aufgaben) gibt, juckte es mir doch seit geraumer Zeit in den Fingern wenn ich an eine Aufgabenstellung dachte, die aus meiner Sicht bisher noch keiner verfasst hatte.
Continue reading “Die Lottery Kata - Aufgabenstellung und (eine) Retrospektive” »
Hendrik Lösch
