Test Driven Development (TDD) - [Mit Profi-Tipps und Beispiel]

Подписаться 17 тыс.

Просмотров 7 тыс.

50% 1

Test Driven Development (TDD - auch Test Driven Design) genannt, ist eine Test First Methode der Softwareentwicklung bei der mit Hilfe von Unit Tests bzw. Unit Testing die Programmierung testgetrieben entwickelt wird. Dabei ist Test Driven Development (TDD) unabhängig von der Programmiersprache, kann also mit Java, C#, Python, JavaScript und anderen verwendet werden. Die testgetriebene Entwicklung (test-driven) mit Test Driven Development (TDD) setzt unit testing im speziellen tdd-cycle "RED", "GREEN" und "REFACTORING" ein. Dabei liefert Test Driven Development (TDD) sowohl funktionierenden Quellcode als auch strukturell gut verständlichen, da in der dritten Phase des Refactorings beispielsweise die Regeln von Clean Code eingehalten werden können. David Tielke zeigt dir in diesem Video alles was Du zu Test Driven Development (TDD) wissen musst, was die Vor und Nachteile von TDD sind und im abschließenden Profi Tipp gibt es noch wertvolle Tipps für den Einsatz von TDD in der Praxis.
Kapitel
[00:00] Start
[02:30] Test-First und Test Driven Development (TDD)
[04:05] Microfeatures in TDD
[06:47] Micro Iterations in TDD
[10:07] Vorteile von Test Driven Development (TDD)
[12:02] Nachteile von Test Driven Development (TDD)
[13:35] Profi Tipps zu TDD
Buch "Test First Codierung" von Ralf Westphal
15% Rabatt (bis 11.09.2021) leanpub.com/test-first-codier...
Erwähnte Videos
Agile Softwareentwicklung: • Agile Softwareentwicklung
Scrum: • Scrum - Von A bis Z [M...
Coding Guidelines: • Code Guidelines / Kodi...
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Наука

Опубликовано:

10 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 36

@bookswiper Год назад

Super Video wieder man merkt da genau Deine Erfahrung und Deine Fähigkeit komplexe Sachverhalte auf den Punkt zu bringen. Grossartig. Ich bin gerade dabei alle Deine Videos abzuabrebiten.

@ernstgreiner5927 3 года назад

Ich kann aus meiner Praxis die Nachteile die du siehst - Kosten/Zeit/Änderbarkeit - auch nicht nachvollziehen. Das man zusätzlich Zeit zum Schreiben von Tests braucht ist klar, diese Zeit lässt sich nur durch Verzicht auf automatisierte Tests einsparen und geht sofort durch manuelle Tests wieder verloren. Automatisierte Tests sind manuellen Tests imho um einen Faktor 100 überlegen, NCrunch testet im Hintergrund immer mit, bei jedem CI run wird getestet und manuell starten kann ich sie auch noch... Der größte Vorteil von TDD ist für mich das feingranularer, testbarer Code entsteht (wurde hier schon als großer Nachteil bezeichnet, da sieht man wie weit hier die Philosophien auseinander liegen) Hohe Testabdeckung fast schon ein Nebenprodukt, 80-90% ist imho hoch genug, 100% bringt wenig erzeugt aber viel Druck, wozu sollte ich ein ToString oder einen getter/setter abtesten? Schlechte Änderbarkeit: Wenn Testcode entsteht der jedes mal wenn Produktivcode geändert wird, mit geändert werden muss, hat man mindestens ein Problem! Roy Osherove beschreibt das ausgezeichnet in "The Art of Unit Testing / 2nd Edition", Kennzeichen von guten/schlechten Tests. (Ausdrückliche Empfehlung meinerseits an jeden _Entwickler_ der testet oder testen will, hier wird praktisch alles abgedeckt, detailliert genug um das Handwerkszeug zum _richtigen_ Testen in den Händen zu haben) Test Behavior, do not test implementation. Wenn man Tests schreibt, die einem helfen weiter zu kommen, und dass darf/soll man gerne tun, eine vorübergehende Stütze im Entwicklungsprozess sozusagen, die aber zu tief in die Implementierung rein geht, dann baut man dieses Hilfskonstrukt und alle unschönen temporären Dinge nachher wieder ab. "...hat man _mindestens_ein_ Problem!" genau das ist der Punkt wo Zeit/Geld liegen bleibt... Das Thema ist unendlich, ich hör' jetzt auf.

@jenskendl7408 3 года назад

Ich kann den genannten Nachteilen auch nicht zustimmen, aber verstehe, wie sie zustande kommen. Liegt wohl an fast 10 Jahren TDD-Erfahrung. Am Anfang hatte ich diese Probleme auch (Zeit, Änderungen brechen Tests...). Das liegt aber wie bei all den anderen Techniken immer dran, wie man die Technik anwendet. Es gibt ein paar Dinge, die ich beobachtet habe (auch an mir), die helfen TDD: - Test wegwerfen, wenn man sie nicht mehr braucht. Im Zuge von TDD entstehen einige Tests, die von nachfolgenden Tests abgelöst werden sollten. - Die Unit nicht zu klein wählen. Das ist ein Klassiker. Ständig heißt es, die Unit sei eine Methode oder Klasse. Das ist nicht so. Die Unit ist eine logische Einheit. Sehr unscharf... Tut mir leid ;). Beim Refactoring zerlegt man gerne mal Klassen / Methoden. Plötzlich meint man, neue Tests zu brauchen und die anderen Klassen zu mocken. Und schwups hat man seine Test-Hölle. Dann ist das zu gut gemeint. Die Konsequenz sind die genannten Nachteile. - Auf Kollaborationstests i.R. verzichten. Das Service X mit Parametern Z und B aufgerufen wurde, ist zwar toll und einfach zu testen, erzeugt aber viele Mocking-Aufwand und die Tests brechen bei jeder kleinen Änderung. Denn viele Mocks koppeln die Tests zu arg an den Produktivcode. Möglichst wenige Mocks verwenden (also die Unit nicht zu klein wählen) ist da besser. Auch einfach mal Stubs selber implementieren mit vernünftigen Defaultwerten, so dass die Tests nicht "gestört" werden bzw. der Testaufbau ständig angepasst werden muss an zig Stellen hilft. - Außerdem ist das Testen von Trivial-code m.E. auch übers Ziel hinausgeschossen. Genauso wie Views. - Und von wegen Red+Green+Refactor: Das Refactor bei jedem Zyklus zu machen ist auch zu viel des Guten. Dann ist auch der Zeitverbrauch ewig. Gibt sicher noch mehr. Muss jetzt aber mal zum Ende kommen... Betreibt man TDD akademisch genau und mechanisch ohne drüber zu reflektieren, dann gibt es die Nachteile, ja. Macht man TDD mit Verstand und Selbstreflexion und lernt draus, dann finde ich, ist es nicht annähernd so schlimm bei den Nachteilen, wie du da so arg mit Nachdruck drauf rumreitest. Auch werde ich mich hüten meine Entwickler (wenn in Lead-Rolle) vorzuschreiben, dass die TDD machen müssen (Allerdings gibts immer wieder Kommentare, wenn was mit TDD hätte vermieden werden können) oder gar nicht dürfen. Es liegt nicht am TDD, wie gut und fehlerfrei der Code ist und wie schnell der Code erzeugt wurde. Liegt immer noch an den Entwicklern selbst.

@rolfhirsch8386 3 года назад

Wieder ein klasse Video. Besonders die Mikrofeatures und am Schluss, wo TDD angewendet werden sollte, haben bei mir weiter zum Verständnis beigetragen. Codierte Tests sind teuer, stehen immer unter hohem Rechtfertigungsdruck und werden gerne mal fallen gelassen. Umso wichtiger ist eine Fokussierung auf zentrale Elemente.

@DavidTielke 3 года назад

Hallo Rolf, schön das Dir das Video gefällt - hab schon so lange Nachrichten bekommen, dass es keine vollständigen und und deutschsprachigen Videos zu dem Thema gibt, da dachte ich mir, es ist mal Zeit :) Ja, der Rechtfertigungsdruck ist in der Tat ein sehr sehr großes Problem, obwohl es eigentlich keins sein sollte. Ich bin immer ein Freund davon pauschal x % der Zeit für Qualität einzuplanen und den Leuten dann eigenverantwortlich zu überlassen, wo und wie diese Zeit verbraucht wird. Das erfordert auf der anderen Seite aber auch, dass entsprechend verantwortungsbewusst damit umgegangen wird. Test Driven Development ist leider einer der Kandidaten, wo das Budget sehr sehr schnell verbraucht wird und die Entwickler realisieren das oft gar nicht. Wie viele Tests habt ihr bei Euch? Gruß David

@rolfhirsch8386 3 года назад

@@DavidTielke Ich bin seit einiger Zeit Scrum Master in einem schon lang laufenden Projekt, bei der dieses Thema auch sträflich vernachlässigt wurde und wird.

@DavidTielke 3 года назад

das ist aber löblich, dass du als Scrum Master das Problem im Fokus hat, sehr gut! Vernachlässigt heißt ihr habt hat keine Tests?

@Humanrebel 11 месяцев назад

Ist man ohne TDD wirklich schneller? Meiner Erfahrung nach muss ich, wenn ich ohne TDD entwickle, sowieso meinen Code manuell mit mehreren Fällen ausprobieren. Dabei finde ich auch Fehler, die ich dann ausbessern muss. Erweiterungen und spätere Bugfixes führen dazu, dass man hinterher die Tests anpassen muss. Wirklich? Wenn man von SOLID das S und das O beachtet vermutlich nicht. Wenn man natürlich auf Klassenebene oder Funktionsebene testet, dann führt jeder Umbau zu Änderungen an den Tests. Versteck man die Details der Domäne hinter einer Facade / API und testet gegen diese, dass hält sich auch das in Grenzen.

@daomonkcoder 3 года назад

Herzlichen Dank!

@DavidTielke 3 года назад

Sehr gerne :)

@WaldemarCoding 3 года назад

TDD ist von der Idee her gut, zumindest für mich durch die genannten Nachteile aber nicht praktikabel. Deine Profi Tipps würde ich daher so unterschreiben. 👍

@user-fu8cf9uw2g 8 месяцев назад

Hallo David, ich lerne gerade für die Abschlußprüfung zum FI-AE (als Späteinsteigerin in die IT sozusagen) und wollte einfach mal anmerken wie gut ich deine Videos finde. Du erklärst nicht zufällig irgendwo die modellgetriebenen Softwareentwicklung? Ich habe Videos auf RU-vid gefunden die wohl eher einer Werbung als einer Erklärung dienen sollen...

@svenvancrombrugge9073 3 года назад

Ich bin bezüglich der Nachteile bei keinem davon deiner Meinung. Die Aussagen halte ich für schlichtweg falsch. Sie sind viel günstiger und viel schneller und viel flexibler. Teilweise TDD Entwicklung, wie von Dir vorgeschlagen halte ich für eine schlechte Idee. Der große Mehrwert liegt an den garantierten 100% Testabdeckung. Der einzige Nachteil den ich sehe ist das ich seitdem ich es das erste mal angewendet habe die Arbeit an nicht mit TDD entwickelten Projekte deutlich weniger schätze.

@DavidTielke 3 года назад

Hallo Sven, das ist auch total in Ordnung - Vor- und Nachteile sind ja auch immer ein Stück weit subjektiv. Mit dem großen Mehrwert von 100% Testabdeckung hast Du vollkommen recht, aber dieser Vorteil kommt zu einem enorm hohen Preis für Neuentwicklung und auch die Wartung - ich kenne fast niemanden der den Preis dafür bezahlen kann / möchte. Deshalb ist der Vorschlag es punktuell einzusetzen ein Kompromiss. Also wenn ich dich richtig verstehe, seid ihr mit TDD schneller und günstiger als ohne? Gruß David

@svenvancrombrugge9073 3 года назад

@@DavidTielke Hallo David Ich komme aus dem Bereich System Administration und Webentwicklung. Die Produkte mit denen ich zu tun habe bauen entsprechend meist stark auf Dienste, Frameworks und Libraries auf, die natürlich nicht mit getestet werden. Die Anwendungen selbst können schnell erstellt und angepasst werden. Das die Verhältnisse bei einem primär Software entwickelndem Unternehmen, das womöglich Desktop Anwendungen entwickelt anders sein können kann ich mir vorstellen. Professionell habe ich leider noch kein Produkt in TDD erstellen können, sondern nur akademisch. Durch eine sichere Testabdeckung & DevOps kann ein produktives Deployment einer Anpassung in Minuten oder Sekunden durchgeführt werden, das geht natürlich nicht wenn erst Wochen lang geprüft werden muss ob keine Seiteneffekte auftreten. Bei einer Desktop Anwendung sind die Wege zur Auslieferung von Änderungen ja ohnehin langwieriger. Bis ein Kunde eine neue Version erhält dauert es ja zumeist etwas länger. Daher sehe ich dort womöglich einen geringeren Gewinn. Ich kann aber immer noch nicht nachvollziehen, wie die Entwicklung durch TDD realistisch langsamer wird. Gefühlt, ja; praktisch aber nicht. Den gleichen Gedanken hatte ich auch, bis ich es gelernt habe. Der Gewinn mag nicht allein TDD zuzusprechen zu sein, sondern der dadurch entstandenen klaren Struktur (die ja auch anders erstellt werden können). Auch wenn ich durch die Tests zumindest unmittelbar mindestens doppelt so viel Code für das gleiche Ergebnis schreibe; ich kann dabei nach der vorherigen Planung des Features (wie von dir im Video erklärt) Stundenlang durch coden, zu regelmäßigen Pausen muss man sich zwingen. Ohne TDD verbringe ich realistisch höchstens 5% wirklich mit coden und den Rest der Zeit mit dem Einlesen, was da überhaupt vorgeht und wie ich eine Anpassung einbringen kann, ohne Schaden anzurichten. Kommentare lügen, Tests nicht. Sie sind on-point Dokumentation über das Verhalten, das zu erwarten ist und können in wenigen Sekunden Sicherheit geben, das man eine Methode richtig verwendet. Dadurch wird meiner Erfahrung nach die Arbeit seht viel effizienter. Wenn Du mit deiner Arbeit bei einem Kunden fertig bist und alles ist entkoppelt ist, Namensmuster werden eingehalten, usw. dann glaube ich dass man ohne TDD schneller arbeiten kann. Einfach weil man sich die Zeit zum Test schreiben spart. Zum Schluss muss ich aber zugeben, das ich meist nur Red->Green, ohne Refactor mache. Das Refactoring kommt dann (vielleicht) später. Das Red->Green geht dank der Besten Gruß Sven

@Humanrebel 7 месяцев назад

Was ist mit den Stufen 1 bis 3? Gar nicht testen? Manuell testen? Manuelle Regressionstest? Sind die wirklich billiger?

@jenseichberg3426 2 года назад

Hallo David, wie kann ich denn Klassifizieren/ erkennen welche Methoden Klassen kritisch sind und diese dann mit TDD punktuell testen ? Gibt es hierzu feste Bewertungskriterien?

@DavidTielke 2 года назад

Hey Jens, ich mache es in Projekten meist so, dass man eine Art Fragenkatalog hat, z.B. Kann der Nutzer seine Arbeit ausführen, wenn diese Methode falsch funktioniert? Ja, dann Kategorie 1 .... Sowas baust Du für alle Kategorien auf, dann habt Ihr ein einheitliches Vorgehen an der Stelle. Gruß David

@jenseichberg3426 2 года назад

@@DavidTielke danke sehr interessante Idee

@myscipper 10 месяцев назад

Über dieses Thema würde ich gerne einmal mit dir diskutieren :) Ich wüsste hier gerne, wieso du die Vorteile von TDD als Nachteile darstellst, nämlich das TDD eine Langzeitinvestition ist. Für eine Software die über eine lange Zeit betrieben werden soll, ist das doch ein absoluter Pluspunkt. Dann sagst du, dass mit TDD die Software Qualität drastisch verbessert wird (und zwar im Vorfeld), aber dann, dass sich dieser "Aufwand" und die daraus entstehenden Kosten nicht lohnen. Und wenn der Fokus bei der Entwicklung neuer Features auf der Entwicklungsgeschwindigkeit liegt, reichen Guidelines nicht mehr aus um eine gewisse Qualität zu etablieren oder zu halten. TDD nur bei hoher Kritikalität verwenden? Wer entscheidet das? Ich bin mir sicher, dass Anwender einer Software gerne alle Funktionen fehlerfrei nutzen möchten. Sei es das Ändern eines Profilbildes oder ein Abbuchung von einem Konto. Du beschreibst den technischen Ablauf von TDD sehr anschaulich, mit RED, GREEN, REFACTOR, aber die Idee dahinter nicht, nämlich das Erstellen einer automatisch ausführbarer Spezifikation. Wenn man TDD anwendet gibt es keine "Tests zu pflegen". Ändern sich die Anforderungen, ändert sich die Spezifikation als erstes, und dann der Code.

@Palladin007 3 года назад

Ich glaube, ein großer Nachteil ist, dass TDD nur sehr kleingranular funktioniert. Bei komplexen Anwendungen braucht man aber einen größeren Blick, um entscheiden zu können, wie etwas entwickelt werden sollte. Diesen Blick hat man aber nicht, also muss man ständig zuvor umgesetzte Funktionalität refaktorisieren. Oder man baut alles so auf, dass sich auch später alles irgendwie zusammen stecken lässt, erreicht damit aber eine deutlich höhere Komplexität, die gerade für die Einarbeitung von neuen Mitarbeitern ein Problem wird. Vermutlich ergibt TDD deshalb tatsächlich nur punktuell Sinn, zumindest zu Beginn eines Projektes sollte eine gewisse Grundlage mit einem größeren Blick geschaffen werden, erst konkrete Features werden dann mit TDD entwickelt. Die vielen Tests testen dann indirekt auch die zuvor geschaffene Grundlage, da die Features ja sehr kleingranular getestet werden und auf dieser Grundlage aufbauen. Ich habe genau 0 Erfahrung mit TDD, aber nach dem Video wirkt das so auf mich. Du hast das so oder so ähnlich in den Nachteilen und am Ende angesprochen. Und die Vorteile sind ja klar: Man hat immer eine solide Testabdeckung und eine Architektur, bei der jede Kleinigkeit getestet wird oder neue Tests (z.B. bei Bugs) leicht ergänzt werden können.

@DavidTielke 3 года назад

Hey, das ist leider immer der Nachteil bei Unit Tests und da ändert auch Test Driven Development nichts dran - für das große Ganze braucht man Integrationstests die meistens aber noch teurer sind. Ernsthaft noch nie mit TDD gearbeitet? :D Gruß David

@ikemkrueger 9 месяцев назад

Geht CI/CD ohne TDD?

3 года назад

Aber bitte nicht vergessen: Tests können die Abwesenheit von Fehlern/Bugs nicht garantieren - sprich: "there are no silver bullets" So meine Sicht - Vorteile: Wenn es das Szenario her gibt und die Komponente in sich recht abgeschlossen und entkoppelt ist lässt sich prima mit TDD entwicklen (Dein Beispiel mit der Stack-Implementation passt da super). Gut gemacht bekomme ich Tests, Dokumentation und eine gute "Oberfläche" (Schnittstelle) meiner Komponente (weil ich sie gleich mit nutze und so Nutzungsprobleme sehe). Nachteile: Bei gekoppelten Komponenten mit Seiteneffekten wird die Verwaltung der Mocks schnell "schwieriger" als das was ich testen will (genau wie bei Unit-Tests) - Bestes Beispiel: Ich möchte meine Datenbankquerys mit TDD erstellen ... viel Spaß dabei! Natürlich ist der Aufwand insgesamt sehr groß und falsch gemacht (um ehrlich zu sein: ich weiß nicht genau wie man es richtig macht) verhindern die Tests am Ende unter Umständen sogar einfache Wart-/Wandelbarkeit (wer kennt das nicht: ich brauche jetzt noch einen Parameter hier ... ach Scheiße 100 Tests im Arsch) ... klar: noch ein (paar?) Wrapper um die Tests rum dann geht das ... vielleicht. Nicht direkt ein Nachteil aber ich habe schon X-mal gehört, dass man mit TDD Design machen kann oder sogar "Algorithmen" entwicklen kann (Uncle Bob lässt grüßen) - meiner Meinung nach totaler Blödsinn - einfach nur mit TDD Anfangen und es wird schon ein Algorithmus/Design rauskommen ist genau wie "einfach mal mit den Coden anfangen ..." - Nachdenken First Development bitte!

@DavidTielke 3 года назад

Absolut richtig, der Satz ist bei der Nachproduktion rausgeflogen, sonst wäre das Video zu lang geworden. Ärgert mich rückwirkend betrachtet ;) Gruß David

@franzwinter1572 3 года назад

Super Video vor allem der Tipp - TDD nur punktuell einsetzen. Hatte da immer eine schwarz/weiß Meinung dazu. Ich habe leider noch nie (streng genommen) TDD gemacht, aber ich hab mir es oft vorgenommen. 😊 Wobei ob man jetzt den Test zuerst schreibt oder gleich nach der Implementierung der Funktion sehe ich jetzt nicht so kritisch. - hab somit quasi TDD gemacht. Ich finde es viel wichtiger das überhaupt Unit Test geschrieben werden, weil das nicht selbstverständlich ist. Ein Kollege hat mir mal einen Nachteil gesagt, denn du auch in deiner Liste von Nachteilen geführt hast. Er hat nen Algo mit TDD entwickelt. Dabei durch TDD lange gebraucht. Schlussendlich war der Algo aber unbrauchbar und somit beim Ihm auch Frust für die viele (unnötige) Arbeit. Vorteile: Naja wenn man ne kritische Software entwickelt die bei einen Fehler hohe Kosten verursacht kann sich das schon auszahlen. Wobei hier da nicht wichtig ist ob unbedingt nach TDD gearbeitet wurde, sondern wie hoch die Test Coverage bzw. wie schlau die Test geschrieben wurden. Ich glaube du bist der Erste der sagt "Vergesst die Aussage das euch TDD langfristig schneller macht". Allgemein gesagt hast du da sicher recht.

@fabianh.5848 2 года назад

TDD wird ja eigentlich fast überall eingesetzt, es gibt Tester und manchmal müssen Programmierer die Tests selbst schreiben.

@DavidTielke 2 года назад

Hey Fabian, naja fast immer leider nicht, habe damals dazu eine Umfrage gemacht und nur 11% nutzen TDD in der Praxis: die Ergebnisse der Umfrage findest Du noch auf meiner Kanalseite im Tab "Community" Gruß David

@Shabazza84 4 месяца назад

Kennt jemand ne Firma die was Komplexes herstellt und ernsthaft TDD nutzt?

@kingigzorn7680 10 месяцев назад

Die Kritik an TDD ist sehr subjektiv. Besonders das Thema Kosten ist halt komplett daneben. Jede Software, die länger als 5 Jahre laufen soll, gewinnt damit