https://mletkin.net/index.php?action=history&feed=atom&title=Testgetriebene_Entwicklung 2026-05-09T05:41:57Z Versionsgeschichte dieser Seite in MimiPedia MediaWiki 1.39.4 https://mletkin.net/index.php?title=Testgetriebene_Entwicklung&diff=81&oldid=prev 2021-08-30T09:15:31Z

<p>Die Seite wurde neu angelegt: „<a href="/index.php?title=Kategorie:Java&amp;action=edit&amp;redlink=1" class="new" title="Kategorie:Java (Seite nicht vorhanden)">Category:Java</a> <a href="/index.php?title=Kategorie:Ausbildung&amp;action=edit&amp;redlink=1" class="new" title="Kategorie:Ausbildung (Seite nicht vorhanden)">Category:Ausbildung</a> __NOTOC__ = Grundgedanke = Der &quot;klassische&quot; Entwickler bekommt eine Problembeschreibung, implementiert dann eine Lös…“</p> <p><b>Neue Seite</b></p><div>[[Category:Java]]<br /> [[Category:Ausbildung]]<br /> __NOTOC__<br /> = Grundgedanke =<br /> Der &quot;klassische&quot; Entwickler bekommt eine Problembeschreibung, implementiert dann<br /> eine Lösung, schaut daß sie funktioniert und ist fertig...<br /> <br /> Der Knackpunkt dabei ist die Frage, wie das Funktionieren überprüft werden soll.<br /> Wir gehen mal davon aus, daß das Problem so beschrieben ist, daß der Entwickler <br /> genau versteht wie das Ergebnis auszusehen hat. Dann kann er mit diesem Wissen<br /> sein Programm überprüfen. Was aber, wenn das Programm geändert oder ergänzt werden<br /> soll? Dann muß der Entwickler erneut überprüfe ob noch alles tut und im Laufe der<br /> Zeit wächst der Test-Aufwand immer weiter an.<br /> <br /> Die Lösung besteht darin, die Überprüfung zu automatisieren. Dann kann eine billige<br /> Maschine die Überprüfung durchführen, während der teure Entwickler &#039;&#039;wichtige&#039;&#039; Dinge tut.<br /> <br /> Der Test wird damit zu einem integralen Bestandteil der Software, wird mit dem<br /> produktiven Code zusammen erstellt und gepflegt.<br /> <br /> = Test First Development =<br /> Wie der Name schon andeutet, wird die Erstellung des Unit-Tests der Erstellung <br /> des Produktiv-Codes vorangestellt. Das hat schon den unmittelbaren Vorteil,<br /> daß nicht implementiert wird, wenn nicht klar ist was getan werden soll.<br /> <br /> Dieses Vorgehen hat damit zwei Schritte:<br /> # Schreibe einen Test der die Funktionalität testet und fehlschlägt (Test ist &quot;rot&quot;)<br /> # Implementiere die Funktionalität bis der Test durchläuft (Test ist &quot;grün&quot;)<br /> <br /> Die Herausforderung besteht -- zumindest am Anfang -- darin, Probleme so in<br /> einzelne Funktionalitäten zu schneiden, daß sie sich in einfachen Unit-Tests<br /> testen lassen. Das Schreiben der Tests ist eine Fähigkeit die man sich durch Üben<br /> recht schnell aneignen kann.<br /> <br /> Dieses Vorgehens hat folgende Vorteile:<br /> * Die Test-Erstellung wird nicht vergessen<br /> * Am Ende der Implementierung ist der Code mit Tests vollständig abgedeckt und dokumentiert<br /> * Der Code kann bei Erweiterung mit Unit-Tests abgesichert werden<br /> * Es ist klar dokumentiert, was der produktive Code tun soll<br /> <br /> = Test Driven Development (TDD) =<br /> Gerät durch das sture Hinzufügen einzelner Features der Blick auf das Gesamtprogramm aus dem Fokus,<br /> wird das Endergebnis als ein Haufen zusammengeworfener Methoden und Klassen dastehen.<br /> Zwar garantieren die Tests, daß das Programm tut was es soll, aber der arme Mensch der das später<br /> erweitern soll wird keine Freude daran haben.<br /> <br /> Durch Hinzufügen eines weiteren Schritts kann man das Verfahren zum TDD ausweiten<br /> wie Kent Beck es im Rahmen des &quot;extreme Programming&quot; beschrieben hat (citation?).<br /> <br /> Halte nach jedem Schritt (bzw. nach jedem grün gewordenen Test) inne und sieh Dir das Gesamtprodukt an.<br /> Überlege Dir:<br /> *Kann ich etwas besser machen?<br /> *Kann ich etwas zusammenfassen?<br /> *Kann ich etwas verallgemeinern?<br /> Setze Maßnahmen, die Dir sinnvoll scheinen um und überprüfe das Ergebnis anhand der Unit-Tests.<br /> <br /> Wichtig dabei ist:<br /> {{quotation|Die Änderungen dürfen keine Änderungen an der bestehende Funktionalität mit sich bringen}}<br /> <br /> Dieses Vorgehen –- man nennt es Refactoring –- erfordert Übung und Erfahrung.<br /> Zögere nicht, Kollegen hinzuzuziehen, wenn Du damit Schwierigkeiten hast oder Anregungen brauchst.</div>

Ullrich