Test-first Codierung
$17.50
Minimal-Preis
$24.50
Empfohlener Preis

Test-first Codierung

Programming with Ease - Teil 1

Über das Buch

Clean Code bedeutet wandlungsfähiger Code. Wandlungsfähigkeit setzt voraus, dass du keine Angst hast, Code zu verändern. Du willst ihn ja nicht unwissentlich verschlimmbessern und das nicht bemerken. Stabilen Code liefern und sofort wissen, wann er reif zur Lieferung ist, sind Grundpfeiler, auf denen deine langfristig hohe Produktivität ruht.

Automatisierte Tests sind seit langem unverzichtbar, wenn es um nachweisbare und nachvollziehbare Korrektheit von Software geht. Leider haben sich automatisierte Tests trotz hervorragender Werkzeugunterstützung und methodischer Empfehlungen wie Test-Driven Development (TDD) und Behavior-Driven Development (BDD) noch nicht als Selbstverständlichkeit durchgesetzt. Die Testabdeckung ist daher in vielen Codebasen, auch frischen, nicht ausreichend, um regressionsfreiheit sicherzustellen. Das Sicherheitsnetz, das automatisierte Tests spannen sollen, damit du darüber angstfrei Codieren kannst, ist weit und/oder löchrig. Woran mag das liegen?

Die Gründe sind sicher vielfältig für dünne Testabdeckung. Einer sticht für mich jedoch heraus: mangelnde Systematik. Es fehlt eine Guideline, wie du als Entwickler, der du mit einem Programmierproblem konfrontiert bist, geradlinig zu testabgedecktem und auch noch ordentlichem Code kommst.

Der red-green-refactor Prozess in TDD ist eine gute Idee - die allerdings in der Praxis von vielen Entwicklern als zu wenig unterstützend erlebt wird. Sie versuchen sich daran zu halten, fühlen sich jedoch schnell entweder allein gelassen oder überfordert bei ihrem Praxisproblem. Aus Frustrations wird dann das Kind mit dem Bade ausgeschüttet und ganz auf automatisierte Tests verzichtet. Oder es wird in der Community nach Hilfe gesucht, die Literatur gewälzt - doch als Antwort wird vor allem "Du musst es eben nochmal und genauer nach den Regeln probieren!" gegeben. Beides ist nicht hilfreich.

Automatisierte Tests sind heute nicht mehr nice to have, sondern gehören zu fachgerechter Arbeitsweise, wenn du professioneller Softwareentwickler sein willst. Sie nicht zu schreiben, sich nicht darum zu bemühen, ist keine Option.

Und mit TDD einfach nochmal und nochmal gegen die Problemwand zu rennen, bringt auch nicht unbedingt die Lösung, sondern erzeugt Frust und Kopfschmerzen. Denn wenn es mit TDD nicht recht klappen will, dann liegt das nicht unbedingt daran, dass du als Entwickler TDD nicht begreifst. Es kann auch daran liegen, dass der TDD Prozess einfach nicht zu deinem Problem passt.

An TDD ist deshalb nichts falsch. Es greift nur schlicht in der Praxis zu kurz. Die Welt der Programmierprobleme ist größer und bunter als das, was in TDD Coding Dojos an kleinen Problemen behandelt wird.

In mehr als 10 Jahren Beschäftigung mit Clean Code Development habe ich mich daher bemüht, ein Vorgehen zu entwickeln, das umfassender und systematischer unterstützt, Probleme in der Codierung zu lösen. Das Motto ist sozusagen: "Keine Angst vor dem blinkenden Cursor in deiner IDE!"

Test-first Codierung als Teil meines Programming with Ease Konzeptes für Clean Code Development nimmt dich an die Hand bei der Bewältigung von Programmierproblemen, die es in fünf Kategorien einteilt:

  • trivial
  • einfach
  • kompliziert
  • komplex
  • chaotisch

Diese Kategorisierung ist an das Cynefin Framework von IBM angelehnt, das Führungskräfte situationsgerecht bei Entscheidungen unterstützen soll.

In der test-first Codierung wird diesen Kategorien aber jeweils ein anderer Problemlösungsansatz zugeordnet. Triviale Probleme gehst du anders an als komplizierte oder komplexe. Klingt logisch, oder? TDD - genauer: classical TDD - hat darin auch seinen Anwendungsfall; doch der ist begrenzt auf nur einen der Problemschwierigkeitsgrade. Und komplexe Probleme sind das nicht.

Gemeinsam ist den Ansätzen für alle Schwierigkeitsgrade, dass du die Codierung mit mindestens einem Test beginnst: dem Akzeptanztest. Deshalb test-first im Titel. Die Begründung ist zwiefach: 1. Wenn du nicht zuerst einen Test schreibst, ist die Wahrscheinlichkeit groß, dass du keinen schreibst. 2. Wenn du dein Denken zuerst auf einen Test richtest, also auf die Außenansicht deiner Lösung, nimmst du die Perspektive eines Benutzers an. Das führt tendenziell zu einer besseren Schnittstelle für deinen Code und zu höherer Testbarkeit.

Test-first Codierung ist aber nicht alles. Es ist nur die letzte Phase eines mehrschrittigen Prozesses, in dem du Anforderungen in hochqualitativen Code umsetzt. Diesen Prozess fasse ich unter dem Titel Programming with Ease zusammen, weil die Programmierung "von Anfang bis Ende" durch mehr Systematik einfacher werden soll.

Allerdings ist Test-first Codierung der erste Band in meiner Programming with Ease Buchreihe. Codierung ist schlicht das, was dir als Softwareentwickler am nächsten liegt und jeden Tag im wahrsten Sinne des Wortes unter den Nägeln brennt. Deshalb will ich dich dabei abholen und unterstützen. Deine Motivation wird bei der Codierung am höchsten sein, etwas Neues zu lernen und deine Gewohnheiten zu verändern. Zumindest hoffe ich das.

Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einem test-first Vorgehen in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Codebeispielen und Abbildungen aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das meine ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Stabilität und Ordnung in deiner Software.

Ich wünsche dir viel Freude bei der Programmierung!

-Ralf Westphal, info@ralfw.de

PS: Wenn du Lust hast, findest du auch einen Überblick darüber, was ich mit Test-first Codierung meine, in einem Youtube-Interview, das David Tielke mit mir geführt hat. In knapp 30 Minuten reiße ich darin die wesentlichen Aspekte des Ansatzes an.

Ver. 1.3.6.20210416

  • Teile dieses Buch

  • Kategorien

    • Automated Software Testing
    • C#
    • Refactoring
  • Rückmeldung

    You must own a copy of this Book to access the forums.

    Contact the Author(s)

Über den Autor

ralfw
Ralf Westphal

Hallo! Mein Name ist Ralf Westphal und ich bin Autor, Trainer, Coach, Berater, Vortragender in Sachen Clean Code Development seit mehr als 10 Jahren. Das Thema nachhaltige Softwareentwicklung hat mich einfach gepackt. Deshalb habe ich 2008/9 die Clean Code Developer Initiative mitgegründet und engagiere mich seitdem dafür, die Programmierung systematischer und einfacher zu machen. Technologien sind nicht mehr mein Ding; mit denen habe ich mich früher stark auseinander gesetzt, auch als ich noch eine Softwarefirma hatte. Seit mehr als 20 Jahren ist mir das Konzeptionelle und Grundlegende immer wichtiger geworden. Nachdenken über Softwareentwicklung, Neues ausprobieren, Bekanntes zu hinterfragen: daran habe ich Spaß. Deshalb heißt meine Firma auch One Man Think Tank.

Inhaltsverzeichnis

  •  
    • Zum Geleit
    • Motivation
      • Programming with Ease
      • Das Softwareuniversum
    • Einleitung
      • Anforderungskategorien
      • It’s the productivity, stupid!
      • Produktivitätskiller
        • Fehlende Korrekheit
        • Fehlender Wert
        • Fehlende Ordnung
      • Zusammenfassung
  • Die Methode
    • 01 - Die Anforderung-Logik Lücke
      • Logik - Der Stoff aus dem Verhalten entsteht
        • Funktionalität
        • Effizienz I - Effizienz durch Algorithmen und Datenstrukturen
        • Effizienz II - Effizienz durch Verteilung
        • Zusammenfassung
      • Von den Anforderungen zur Logik
        • Logik schwer definierbar
        • Die Phasen der Programmierung
        • Zusammenfassung
      • Übungsaufgaben
    • 02 - Vorläufig codieren im Chaos
      • Das Nein der Codierung
      • Prototyping to the Rescue
      • Die Schwierigkeit der Umsetzung einstufen
      • Zusammenfassung
    • 03 - Sofort codieren in der Trivialität
      • Trivialität als Gegenteil von Chaos
      • Vorsicht vor Selbstüberschätzung!
    • 04 - Schrittweise codieren in der Einfachheit
      • Trittsteine legen
        • Pear Programming
      • Die Kunst der Problemskalierung
        • Sichtbarkeit von Variationsdimensionen
        • Variationen ordnen
      • Am Beispiel
      • Zusammenfassung
      • Übungsaufgaben
    • 05 - Komplementär codieren in der Kompliziertheit
      • Zerlegung in komplementäre Teilprobleme
        • Funktionen repräsentieren Lösungen
      • Integration Operation Segregation Principle
      • Zerlegungsbeispiel I
        • Leitfragen für die Zerlegung
        • Analyse & Entwurf
        • Codierung
        • Reflexion
      • Buddelschiff Programmierung
      • Zerlegungsbeispiel II
        • Bottom-up Codierung
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 06 - Tests als Treiber der Modularisierung
      • Akzeptanztests
        • Triviale Probleme
        • Einfache Probleme
        • Komplizierte Probleme
      • Gerüsttests
        • Gerüsttestfälle erhalten I - Akzeptanztests
        • Gerüsttestfälle erhalten II - Modultests
      • Zusammenfassung
      • Übungsaufgaben
    • 07 - Testbarkeit steigern mit Surrogaten
      • Logik dynamisch binden
        • Statische Bindung
        • Dynamische Bindung mit Funktionszeigern
        • Dynamische Bindung mit Objekten
        • Zusammenfassung
      • Surrogate in Tests einsetzen
        • Extraktion einer Klasse und Abstraktion mit Interface
        • Injektion einer Objektfabrik
        • Surrogate unterschieben
        • Reflexion
      • IOSP over Surrogates
        • Extraktion eines Belangs
        • Refactoring to Functional Core
        • Schritte in die Objektorientierung
      • Zusammenfassung
      • Übungsaufgaben
    • 08 - Experimentell codieren in der Komplexität
      • Experimentelles Vorgehen im Testcode
        • TDD as if you meant it (TDDaiymi)
      • Beispiel #1: FromRoman revisted
        • Inkrement 1
        • Inkrement 2
        • Inkrement 3
        • Inkrement 4
        • Inkrement 5
        • Inkrement 6
        • Reflexion
      • Beispiel #2: Eine ruhige Bowlingkugel schieben
        • Analyse
        • Codierung
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 09 - Test-first refaktorisieren
      • Frustrierende Lektüre
        • Fehlende Bedeutung
        • Fehlende Zusammenhänge
        • Fehlende Testbarkeit
      • Warum refaktorisieren?
        • Softwarewartung erhält Ordnung proaktiv
      • Schrittweise aufräumen I
        • Bestimme das System-to-Refactor (S2R)
        • Refactor to Test-First
      • Schrittweise aufräumen II
        • Refactor to IOSP
        • Refactor to Modules
        • Dokumentieren
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 10 - Finale mit Testmatrix
  • Anhang - Musterlösungen
    • Musterlösung: 01 - Die Anforderung-Logik Lücke
      • Aufgabe 1 - Gründe für automatisiertes Testen
        • Beispielhafte Gründe für die Testautomatisierung
        • Beispielhafte Gründe für test-first Testautomatisierung
      • Aufgabe 2 - Eine Anwendung test-first entwickeln
        • Analyse
        • Entwurf der Persistenz
        • Codierung
    • Musterlösung: 04 - Schrittweise codieren in der Einfachheit
      • Aufgabe 1 - Einschätzung des Schwierigkeitsgrades
        • Mathematischen Ausdruck berechnen
        • Game-of-Life
        • NQueen
        • Binärzahlenkonvertierung
      • Aufgabe 2 - Römische Zahlen in Dezimalzahlen wandeln
        • Verständnis dokumentieren
        • Inkrementelle Testfälle definieren
        • Test-first codieren
      • Reflexion
    • Musterlösung: 05 - Komplementär codieren in der Kompliziertheit
      • Aufgabe 1 - Römische Zahlen kompliziert wandeln
        • Zerlegung für Lösungsansatz 1
        • Zerlegung für Lösungsansatz 2
        • Reflexion
      • Aufgabe 2 - Game of Life
        • Verständnis dokumentieren
        • Schrittweise zerlegen
        • Akzeptanztests
        • Teilprobleme bottom-up lösen
        • Reflexion
    • Musterlösung: 06 - Tests als Treiber der Modularisierung
      • Analyse
        • Inkrementelle Teilprobleme
      • Zerlegung der Inkremente inkl. Codierung
        • Akzeptanztest
        • Inkrement I
        • Inkrement II
        • Inkrement III
        • Inkrement IV
        • Inkrement V
        • Reflexion
      • Refaktorisierung mit nachträglicher Modularisierung
      • Zusammenfassung
    • Musterlösung: 07 - Testbarkeit steigern mit Surrogaten
      • Aufgabe 1 - CSV-Daten tabellieren
        • Analyse
        • Planung
        • Umsetzung
        • Reflexion
      • Aufgabe 2 - Game-of-Life
        • Analyse
        • Planung
        • Umsetzung
        • Reflexion
      • Zusammenfassung
    • Musterlösung: 08 - Experimentell codieren in der Komplexität
      • Analyse
      • Planung
        • Zerlegung in Teilprobleme
        • Inkrementelle Testfälle für die komplexen Probleme
      • Codierung
        • Akzeptanztests
        • TDDaiymi - Lange Worte zerschneiden
        • TDDaiymi - Zeilen zusammensetzen
        • Triviale Probleme lösen
        • Integration
        • Refaktorisierung in Module
      • Reflexion
        • Zurückhaltung als Tugend
    • Musterlösung: 09 - Test-first refaktorisieren
      • Abgrenzung des System to Refactor (S2R)
      • Characterization Test
        • S2R Entry Point testbar machen
        • Console kapseln
        • Characterization Test aufsetzen
      • Verantwortlichkeiten identifizieren
      • Entwurf der neuen Codestruktur
      • Funktionen extrahieren
        • Kommandozeilenanalyse
        • HexDump I - Entzerrung der Logik
        • HexDump II - Refactor to IOSP
      • Refactor to Modules
      • Bonus Verbesserungen
        • Auflösung einer logischen Abhängigkeit
        • Fehlerkorrektur in der Ausgabe
      • Zusammenfassung
  • Anmerkungen

Die bedingungslose Leanpub Garantie: Kein Risiko, 100% Zufriedenheit

Innerhalb von 60 Tagen ab Kauf kannst du dein Geld zu 100% zurückverlangen, bei jedem Leanpub-Kauf, in nur zwei Klicks. Wir bearbeiten die Erstattungen manuell, daher dauert es ein paar Tage, bis der Betrag ankommt.
Lese die kompletten Bedingungen.

Verdienen Sie $8 bei einem Kauf von $10 und $16 bei einem Kauf von $20

Wir zahlen 80% Tantiemen bei Käufen von $7,99 oder mehr und 80% Tantiemen abzüglich einer Pauschalgebühr von 50 Cent bei Käufen zwischen $0,99 und $7,98. Sie verdienen $8 bei einem Verkauf von $10 und $16 bei einem Verkauf von $20. Wenn wir also 5000 nicht zurückgegebene Exemplare Ihres Buches für $20 verkaufen, verdienen Sie $80,000.

(Ja, einige Autoren haben auf Leanpub bereits viel mehr verdient.)

Tatsächlich haben Autoren durch das Schreiben, Veröffentlichen und Verkaufen auf Leanpubüber 13 Millionen Dollar verdient.

Erfahren Sie mehr über das Schreiben auf Leanpub

Kostenlose Updates. Ohne DRM.

Mit dem Kauf auf Leanpub bekommst Du kostenlose Updates solange der Autor Änderungen vornimmt! Viele Autoren veröffentlichen ihre Bücher während des Schreibens. Alle Leser bekommen dann kostenlose Updates, egal wann sie das Buch gekauft haben oder wie viel sie bezahlt haben (auch wenn es kostenlos war).

Die meisten Leanpub Bücher sind erhältlich als PDF (für Computer) oder EPUB (für Handy, Tablet, Kindle). Die verfügbaren Formate sind oben rechts auf dieser Seite angezeigt.

Leanpub Bücher kommen ohne DRM Kopierschutz Firlefanz, sodass Du sie problemlos auf jedem unterstützten Gerät lesen kannst.

Erfahren Sie mehr über Leanpubs E-Book-Formate und wo Sie sie lesen können

Schreiben und veröffentlichen auf Leanpub

Autoren und Verleger nutzen Leanpub, um erstaunliche Fortschrittsbücher zu veröffentlichen und E-Books zu vervollständigen. Sie können auch auf Leanpub schreiben, veröffentlichen und verkaufen! Leanpub ist eine leistungsstarke Plattform für ernsthafte Autoren und kombiniert einen einfachen, eleganten Schreib- und Publishing-Workflow mit einem Store, der sich auf den Verkauf von E-Books konzentriert. Leanpub ist eine magische Schreibmaschine für Autoren: Schreiben Sie einfach in Klartext, und um Ihr E-Book zu veröffentlichen, klicken Sie einfach auf eine Schaltfläche. Es ist wirklich so einfach.

Erfahren Sie mehr über das Schreiben auf Leanpub