Diskussion:Testgetriebene Entwicklung

Übersetzung

Im hiesigen Sprachgebrauch hat sich die Übersetzung 'Testgetriebene Entwicklung' eingebürgert.

Könnte man den Artikel entsprechend umbenennen? Das wäre super!

Hab ein redirect Testgetriebene Entwicklung auf hierher draufgemacht. Damit erledigt? -- Test-tools 09:31, 22. Aug 2005 (CEST)

Zeitdruck erzeugen?

"Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen und wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile:"

Jemand könnte das falsch verstehen. Die korrekte Formulierung wäre: Mikroiterationen sollten in so kleine Arbeitsschritte gegliedert sein, dass jede innerhalb weniger Minuten zu erledigen ist. Hierbei darf kein Zeitdruck entstehen. Testen ist eine langwierige und schwierige Aufgabe, die hohe Konzentration erfordert. (nicht signierter Beitrag von 89.0.143.125 (Diskussion) 08:39, 8. Mär. 2013 (CET))

Abgrenzung extreme Testing

Wenn man diesen Artikel liest könnte man meinen extreme Testing und testgetriebene Entwicklung seien Synonyme. Im Artikel extreme Testin liest sich das ganz anders. Ist es das gleiche? Falls nein, sollte man das hier auch klar sagen und evtl. die Unterschiede herrausstellen. --Badenserbub 15:21, 20. Apr 2006 (CEST)

Verschiebung

Am besten wäre es, ein Admin löscht Testgetriebene Entwicklung und verschiebt anschließend diesen Artikel nach Testgetriebene Entwicklung, dann passt alles von den Links bis zur History außer den neuesten Änderungen, die kann man aber manuell leicht nachziehen denke ich.--ChristianHujer 19:20, 3. Mär 2006 (CET)

Einigt euch bitte vorher auf das bevorzugte Lemma, dann wendet euch an einen Admin. Gruß --Revvar %&§ 10:25, 18. Mär 2006 (CET)

Testgetriebene Entwicklung ist schon besser. Beide Begriffe werden verwendet, aber Testgetriebene Entwicklung hat sich als die häufigere Übersetzung von Test First Programming gegenüber Testgesteuerte Entwicklung durchgesetzt. Also bitte nach Testgetriebene Entwicklung verschieben. --ChristianHujer 12:32, 18. Mär 2006 (CET)

Vollkommen unverständlich?

Ich halte den Artikel für absolut unnütz (und entschuldigung für das harsche Urteil). Ich zähle aber mal meine Kritikpunkte auf, vielleicht könnt ihr sie nachvollziehen:

• Absatz "Die klassische Methode"
  • Welche denn? Die "normale" Software-Entwicklung, oder die "normale" Test-driven-Entwicklung?
  • Und dann werden erst einmal Vor- und Nachteile aufgezählt, aber kein Vorgehen definiert. Häh? Und immer noch - von was?
• Stichwort Vorgehen: Wo steht hier eine klare Definition? Irgendwo im Nebensatz habe ich eine Andeutung gefunden, aber sonst nur Vorteile, Nachteile
• Abschnitt "Vorgehensweise": Dieser unterteilt sich in die DEFINITIONEN von Unit-Tests, System-Tests und deren Gemeinsamkeiten, aber einen Ablauf finde ich hier auch nicht.

Ehrlich, das finde ich nicht besonders informativ für jemanden, der sich einen Überblick verschaffen möchte. Ich bin allerdings selbst nicht sicher genug, sonst hätte ich mich daran versucht.

-- The-Me 17:09, 15. Okt. 2008 (CEST)

Du hast den Artikel aber schon genauer gelesen oder? Naja ich habe es jetzt jedenfalls versucht zu verdeutlichen. Kent Beck definiert im Wesentlichen, das unter Unit-Tests definierte Vorgehen als testgetriebene Entwicklung.-Ma-Lik ? +/- 19:03, 15. Okt. 2008 (CEST)

Für bestimmte Fachleute mag der Artikel zu schwammig sein, aber ich finde gerade die umgangssprachliche Formulierung nachvollziehbar. Jeder klassische Programmierer hat die beschriebenen Nachteile der klassischen Methode schon erfahren und versteht daher, was mit der TDD erreicht bzw. vermieden werden soll. (nicht signierter Beitrag von 2003:45:2B08:BE01:B91B:4653:C928:9A56 (Diskussion | Beiträge) 10:47, 14. Mär. 2013 (CET))

TDD vs. agile Softwareentwicklung?

"Als testgetriebene Entwicklung [...] bezeichnet man die Verwendung Agiler Methoden ..." -> Da muss ich grade mal einspruch erheben! Die Prinzipien der agilen Softwareentwicklung erwähnen das Wort Test nicht einmal... Streng genommen würde ich sagen: Test-Driven-Development IST EINE Methode, die im Agilen Development häufig verwendet wird.--Doc ter ror 15:53, 16. Jan. 2009 (CET)

Geändert.--Ma-Lik ? +/- 17:03, 16. Jan. 2009 (CET)

TDD als Methode zur Verbesserung des Designs

Ein Aspekt fehlt hier völlig: Durch Einsatz von TDD wird der Entwickler quasi gezwungen kleine, sauber abgrenzbare Softwarebausteine zu schreiben. Übermässig komplexe Klassen und stark verzahnte Strukturen (en:Big Ball of Mud) können gar nicht entstehen. Es geht also nicht nur ums Testen sondern auch um das Design. --78.43.176.32 23:06, 25. Sep. 2009 (CEST)

Ich habe gerade etwas dazu geschrieben (bevor ich deinen Beitrag hier gelesen hatte), was ich aus den englischen WP übersetzt habe. Ich habe das unter Testgetriebene Entwicklung#Gemeinsamkeiten zwischen Testgetriebener Entwicklung mit Systemtests und Unit-Tests eingetragen, weil da schon eine Aufzählung angefangen worden war. Dabei sind mir 2 Sachen aufgefallen:

1. Es werden in dieser Aufzählung Vorteile von TDD erwähnt, die m.E. samt und sonders nur Vorteile der Testgetriebenen Entwicklung mit Unit-Tests sind, weil sie durch Testgetriebene Entwicklung mit Systemtests gar nicht erzielt werden können. Die sind unter Gemeinsamkeiten also fehl am Platze.
2. Ich bezweifle, dass man im Falle der Systemtests überhaupt von Testgetriebener Entwicklung sprechen kann, denn ein Systemtest setzt ja erst an einem Punkt ein, bei dem die Software schon integriert wurde, also viel zu spät. Ich würde den Artikel umschreiben und die Testgetriebene Entwicklung mit Systemtests entfernen oder höchstens als Randnotiz erwähnen. --史慧开 12:06, 4. Nov. 2009 (CET)

Das sehe ich auch so.

Die Überschrift „Gemeinsamkeiten zwischen Testgetriebener Entwicklung mit Systemtests und Unit-Tests“ ist ohnehin allein aus sprachlichen Gründen entweder unsinnig oder doch zumindest missverständlich. Testgetriebene Entwicklung mit Systemtests, wenn es denn das gibt, ist nach Begriff eine Methodik, Unit-Tests dagegen sind ein Werkzeug. Zwischen Dingen, die verschiedenen Kategorien angehören, mag es ja manchmal Gemeinsamkeiten geben, aber was für eine sollte zwischen einer Vorgehensweise und einem Instrument bestehen? Ähnlich absurd wäre Gemeinsamkeiten zwischen Écriture automatique und Bleistiften.

Die andere Möglichkeit: Es war eigentlich gemeint „Gemeinsamkeiten zwischen Testgetriebener Entwicklung mit Systemtests und Testgetriebener Entwicklung mit Unit-Tests“. Bei der ersten Alternative sehe ich wie 史慧开 nicht, wie das alleinige Praktizieren von Systemtests die Entwicklung testgetrieben machen könnte. Da fehlt schlichtweg die schnelle Transmission zwischen dem „Aha, klappt wieder mal nicht“ und „Ich weiß auch schon, wo der Fehler liegen muss, weil ich ja zuletzt nur das und das geändert habe“ – „zuletzt“ könnte hier ja durchaus eine Woche umfassen. Die entgegengestellte Alternative dagegen ist wohl pleonastisch; testgetriebene Entwicklung umfasst wohl zwingend kleinteiliges, ständiges, wiederholtes Testen, wie sollte man das hinkriegen ohne Unittests? Kleinteiliges Testen profitiert ja gerade von der Codelokalität in der getesteten Software, hat man die nicht, wird das wenig ertragreich.

-- Silvicola Diskussion Silvicola 00:57, 5. Nov. 2009 (CET)

Build-Server notwendig?

Unter "Werkzeuge" steht, dass "ein Werkzeug zur Build-Automatisierung wie etwa CruiseControl" "vordringlich gebraucht" wird. Was richtig ist, ist dass ich auf meinem Entwicklerrechner die Möglichkeit haben muss, schnell zu einem ausführbaren Zustand zu kommen, um die Tests ausführen zu können. Dafür braucht es im Allgemeinen aber höchstens einen Compiler - in interpretierten Sprachen noch nicht einmal den. Und Cruise Control ist nicht mal ein Werkzeug zur Build-Automatisierung, selbst wenn man eines bräuchte. (nicht signierter Beitrag von Ilja Preuß (Diskussion | Beiträge) 19:44, 23. Feb. 2010 (CET))

Man sollte ausserdem festhalten, dass es sich bei Maven und Ant um Buildtools handelt. (nicht signierter Beitrag von 217.114.120.86 (Diskussion) 15:13, 8. Mai 2013 (CEST))

Link mit Werbung

Der Link "Bessere Codequalität und Kosteneinsparungen durch Einheittests/Modultests" verweist zwar auf einen informativen Text. Ist aber letztlich Werbung von einer Firma, die Test-Tools verkauft. Geht das D'accord mit den Wikipedia-Regeln? (nicht signierter Beitrag von 194.95.112.81 (Diskussion) 18:48, 20. Feb. 2013 (CET))

Informative Links sollte man nicht ehrenwerten Prinzipien opfern. Aber ein Hinweis auf den Charakter als Werbung könnte nicht schaden. (nicht signierter Beitrag von 2003:45:2B08:BE01:B91B:4653:C928:9A56 (Diskussion | Beiträge) 10:47, 14. Mär. 2013 (CET))

Abschnitte Werkzeuge und Literatur Java-lastig

Die Literatur enhält leider fast nur Bücher und PDFs zum Thema JUnit. Sinnvoll wären Ergänzugen zu anderen Sprachen und eine Überprüfung auf evtl. Redundanz.

• Vorschlag: James W. Grenning: Test-Driven Development for Embedded C. The Pragmatic Programmers, 2011, ISBN 978-1-934356-62-3. 

--Trac3R (Diskussion) 10:21, 22. Mai 2014 (CEST)

Ziele

Aus dem Artikel wird nicht klar, welche Zielsetzung der Einsatz von testgetriebener Entwicklung verfolgt. (nicht signierter Beitrag von 188.96.232.97 (Diskussion) 06:21, 1. Jul 2015 (CEST))

letzter satz im Abschnitt 1:

Die Methode der testgetriebenen Entwicklung versucht den Gründen für eine nicht ausreichende Testabdeckung und einigen Nachteilen der White-Box-Tests entgegenzuwirken.

ist vielleicht etwas zu vorsichtig formuliert, aber dennoch eine valide Darstellung des Ziels, denke ich.

TT (Diskussion) 09:23, 3. Jul. 2015 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://stmj.developertests.de/
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (6) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://stmj.developertests.de/

– GiftBot (Diskussion) 05:44, 25. Dez. 2015 (CET)

Abbildung "Typischer testgetriebener Entwicklungsprozess" - Endlosschleife im letzten Block "Qualitätssicherung" ?

Ist eine Endlosschleife im letzten Block im Bereich Qualitätssicherung möglich? "Merge der Änderungen in den Hauptzweig" -> Qualitätskontrolle (gatedCheck-In, Peer Review) -> abgelehnt -> "Merge der Änderungen in den Hauptzweig" -> Qualitätskontrolle (gatedCheck-In, Peer Review) -> abgelehnt ->.... (nicht signierter Beitrag von HandsomeRob42 (Diskussion | Beiträge) 09:39, 7. Sep. 2016 (CEST))