{"id":21418,"date":"2021-08-27T10:59:43","date_gmt":"2021-08-27T08:59:43","guid":{"rendered":"https:\/\/www.software-developer-india.com\/was-ist-testgetriebene-entwicklung-oder-tdd\/"},"modified":"2021-08-27T11:00:06","modified_gmt":"2021-08-27T09:00:06","slug":"was-ist-testgetriebene-entwicklung-oder-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/de\/was-ist-testgetriebene-entwicklung-oder-tdd\/","title":{"rendered":"Was ist testgetriebene Entwicklung? Oder TDD?"},"content":{"rendered":"\n

Was ist testgetriebene Entwicklung? Oder TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Test Driven Development oder TDD, wie es in Entwicklerkreisen gerne genannt wird, ist ein wichtiger Aspekt des Softwareentwicklungsprozesses. Durch diesen Ansatz ist es einfacher zu testen, was ein bestimmter Code leisten w\u00fcrde. Testf\u00e4lle f\u00fcr jede Funktionalit\u00e4t der Softwareanwendung werden erstellt, und wenn eine bestimmte Funktionalit\u00e4t in einem Test fehlschl\u00e4gt, wird der Code \u00fcberarbeitet und neue Codes erstellt. Auch der neue Code m\u00fcsste den Test bestehen und fehlerfrei sein. Der Entwickler muss nur dann einen neuen Code schreiben, wenn der automatisierte Test des Codes fehlgeschlagen ist, sodass es f\u00fcr jede noch so kleine Funktionalit\u00e4t einen Testfall gibt. Und bei TDD dreht sich alles darum, Tests f\u00fcr jede einzelne Funktionalit\u00e4t in der Anwendung zu entwerfen und zu entwickeln. <\/p>\n\n

Der Name Test Driven Development weist darauf hin, dass es der Prozess der richtigen Durchf\u00fchrung von Tests ist, der die Softwareentwicklung vorantreibt. Daher leitet der Prozess selbst seine Wurzeln aus der agilen Methodik und der Extreme-Programmierung. Dieser Prozess stellt sicher, dass Entwickler widerstandsf\u00e4higen und langfristigen Code erstellen und pflegen. <\/p>\n\n

Der Prozess f\u00fcr TDD besteht also darin, zuerst den Komponententest zu schreiben und dann, wenn der Test fehlschl\u00e4gt, die Code\u00e4nderungen zu implementieren. Dies hilft auch, Codeduplizierungen zu vermeiden. Das Ganze l\u00e4uft darauf ab, fehlgeschlagene Tests vor der eigentlichen Entwicklung zu schreiben und zu korrigieren. Damit der TDD erfolgreich funktioniert, ist es jedoch ratsam, die Testf\u00e4lle in einfache Testf\u00e4lle zu schreiben. F\u00fcr eine komplexe Gesch\u00e4ftslogik w\u00e4re es wirklich schwierig, eine Kombination von Testf\u00e4llen zu schreiben und den vollen Erfolg zu erzielen. Es besteht die M\u00f6glichkeit, dass Sie einige Tests verpassen, daher ist dies keine leichte Aufgabe. <\/p>\n\n

Unterschied zwischen TDD und traditionellem Testen<\/strong><\/h3>\n\n

Herk\u00f6mmliche Tests sind zeitaufwendiger als TDD und basieren auf der Wiederholung eines kurzen Entwicklungszyklus. Zuerst wird der Test von Anfang an geschrieben, dann wird der Programmcode geschrieben, gefolgt von dem gew\u00fcnschten Verhalten des Systems. Wenn der schriftliche Test bestanden ist (Pr\u00fcfung der Korrektheit der Arbeit des ungeschriebenen Codes), wird ein Refactoring des geschriebenen Codes durchgef\u00fchrt. <\/p>\n\n

Anfangs wird TDD auch zeitaufw\u00e4ndig sein, aber mit der Zeit wird sich der Entwickler daran gew\u00f6hnen, da der Entwicklungsprozess strukturierter wird. Wenn Sie beispielsweise einen Entwickler einstellen, wird dieser entscheiden, was er schreibt und dann, wie er es schreibt. <\/p>\n\n

Herk\u00f6mmliche Tests sind erfolgreich, wenn sie einen oder mehrere Fehler richtig finden. Genauso wie TDD. Fehler zu finden ist eigentlich ein gutes Zeichen, denn dann wissen Sie, dass Sie den Fehler beheben und von dort aus weitermachen m\u00fcssen. TDD gibt Ihnen auch mehr Sicherheit, wenn Sie das Programm freigeben, und stellt sicher, dass es die Anforderungen erf\u00fcllt, f\u00fcr die es definiert ist. <\/p>\n\n

Beim traditionellen Testen liegt der Fokus mehr auf dem Testfalldesign, w\u00e4hrend bei TDD der Fokus mehr auf dem Produktionscode liegt, um zu \u00fcberpr\u00fcfen, ob das Testen nach Plan funktioniert. <\/p>\n\n

TDD bietet Ihnen eine 100%ige Testabdeckung, wobei f\u00fcr jede einzelne Codezeile getestet wird, was bei herk\u00f6mmlichen Tests nicht der Fall ist.<\/p>\n\n

Wenn der Projektumfang wirklich gro\u00df ist, muss man bei der Durchf\u00fchrung der Tests sehr gr\u00fcndlich vorgehen. Und es besteht die M\u00f6glichkeit, dass sich die Tests verz\u00f6gern und die Budget- und Zeitbeschr\u00e4nkungen \u00fcberschreiten. <\/p>\n\n

TDD mag schwer zu schreiben sein und die Entwicklungszeit verlangsamen, aber auf lange Sicht w\u00fcrde es sich definitiv auszahlen. <\/p>\n\n

Ein weiterer Nachteil von TDD besteht darin, dass das Konzept schwer auf existierenden Legacy-Code anzuwenden ist. <\/p>\n\n

Es ist immer gut, wenn der Test fehlschl\u00e4gt, bevor Sie ein Projekt freigeben, denn dann wissen Sie, dass Sie einen g\u00fcltigen Test durchgef\u00fchrt haben. Durch TDD wissen Sie, dass Ihr System die Anforderungen erf\u00fcllt, f\u00fcr die es entwickelt wurde. Der Fokus liegt also eher auf Produktionscode f\u00fcr TDD, da dieser sicherstellt, dass das Testen richtig funktioniert. Und wenn die Software alle daf\u00fcr vorgesehenen Anforderungen erf\u00fcllt.<\/p>\n\n

Die verschiedenen Phasen einer testgetriebenen Entwicklung<\/strong><\/h3>\n\n

Es gibt drei verschiedene Stufen von TDD: Rot, Gr\u00fcn und Refactor<\/p>\n\n

Befolgen Sie diese Reihenfolge der Schritte, um sicherzustellen, dass Sie Tests f\u00fcr den Code haben, den Sie schreiben, sodass Sie die Codes nur f\u00fcr die Tests schreiben m\u00fcssen, die Sie gerade durchf\u00fchren. <\/p>\n\n

Die Rote B\u00fchne<\/strong><\/h3>\n\n

Die Idee der roten Phase ist, den Test zum Scheitern zu bringen, und auch die schwierigste Phase, da die Entwicklung keinen Code schreiben muss. Neue Entwickler m\u00fcssen es schwierig finden, weil sie verwirrt w\u00e4ren, was sie testen sollen, ohne den Code daf\u00fcr zu haben. Aber es ist eine gewohnheitsm\u00e4\u00dfige Sache und mit der Erfahrung wird es glatt. Der erste Test wird geschrieben, ohne Code zu schreiben und Klasse und Methode zu deklarieren, und der Test wird einen Kompilierungsfehler aufweisen. Der n\u00e4chste Schritt w\u00e4re, den Kompilierungsfehler zu beheben und den Test auszuf\u00fchren, um ihn zu fehlschlagen. Dies verursacht die rote Flagge.<\/p>\n\n

Die Gr\u00fcne Phase<\/strong><\/h3>\n\n

Nach der roten Phase w\u00e4re der n\u00e4chste Schritt, den Code zu schreiben. Dieser Code muss den ersten Test bestehen. Gerade genug Code zu schreiben, um sicherzustellen, dass nur der erste Test besteht, ist eine H\u00fcrde, vor der viele Entwickler anfangs stehen. Denn im n\u00e4chsten Test m\u00fcsste es fehlschlagen, gefolgt von neuem Code, um sie zu bestehen. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

Die Refraktorphase<\/strong><\/h3>\n\n

In den ersten beiden Phasen, in denen der Test erst durchfallen und dann bestehen muss, war es das Ziel, die Tests dann zum Bestehen zu bringen. In der Refraktor-Phase m\u00fcssen jedoch andere Faktoren ber\u00fccksichtigt werden, wie die Codequalit\u00e4t, die Wartbarkeit des Codes, die Lesbarkeit des Codes usw. Der Fokus liegt hier also auf diesen Aspekten, auf die sich die Unit-Tests konzentrieren werden. In der Refactoring-Phase m\u00fcssen Sie sich keine Sorgen \u00fcber fehlende Funktionalit\u00e4t machen, da die Testf\u00e4lle bei Code\u00e4nderungen automatisch auch dem funktionalen Teil entsprechen.<\/p>\n\n

TDD passt gut in die agile Methodik<\/strong><\/h3>\n\n

Es liegt auf der Hand, dass sich Projektanforderungen bis weit in die Entwicklungsphase hinein \u00e4ndern k\u00f6nnen, so dass die Zusammenarbeit von TDD mit der agilen Entwicklung definitiv zum Erfolg f\u00fchrt und Projekte entsprechend den Kundenanforderungen entwickelt. Mit testgetriebener Entwicklung erhalten Sie ein fr\u00fcheres Feedback zum Projekt, an dem Sie problemlos arbeiten k\u00f6nnen. <\/p>\n\n

Es w\u00fcrde auch dazu beitragen, die kritischen Engp\u00e4sse zu antizipieren und zu reduzieren und sicherzustellen, dass das Projekt wie geplant voranschreitet. Entwicklerteams k\u00f6nnen viel Zeit sparen, da die Tests viel fr\u00fcher in der Projektentwicklung erstellt werden und sie sich nicht um umfangreiche Testskripte k\u00fcmmern m\u00fcssen. <\/p>\n\n

Fazit<\/strong><\/h3>\n\n

Test Driven Development ist eine Technik, die zwar zeitaufw\u00e4ndig ist, aber insofern wertvoll ist, als sie Ihr Projekt in die richtige Richtung lenkt, indem sie korrektes Feedback zum Projekt erh\u00e4lt und Fehler erkennt. Es ist jedoch eine viel bessere Option als herk\u00f6mmliche Tests, da es mehr Zeit und Geld erfordert. <\/p>\n\n

Interessante Links:<\/p>\n\n

Testgetriebene Entwicklung: Was es ist und was es nicht ist.<\/a><\/p>\n\n

Mehr Informationen \u00fcber Testgetriebene Entwicklung<\/a><\/p>\n\n

Bilder: Canva<\/p>\n\n

\"\"<\/figure><\/div>\n\n

Der Autor: Sascha Thattil arbeitet bei Software-Developer-India.com die zur YUHIRO Gruppe geh\u00f6rt. YUHIRO ist ein deutsch-indisches Unternehmen, das Programmierer an IT-Unternehmen, Agenturen und IT-Abteilungen vermittelt.<\/p>\n