Wer von euch hat schon mal was von Test Driven Development gehört und praktiziert es aktiv?

Ich selbst versuche nun schon seit einer Weile meine Kollegen und Kunden dazu zu motivieren TDD zu praktizieren. Und nein, es ist leider noch nicht längst überall Standard.

Insbesondere die unter euch, welche noch Schüler und Studenten sind, sollten sich dringend damit auseinander setzen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich versuche es zu machen, habe aber schon länger keine neuen Tests geschrieben.
Die Hauptzusammenfassung des Problems ist "Legacy Code".
Spezifischer sind es die Fragen wie man gewisse Klassen loseisen kann und wie man gewisse Dinge überhaupt testen kann.

Dennoch kann ich jedem empfehlen sich damit auseinander zusetzen. Es ist wirklich genial wenn man Tests stehen hat. Es gibt nichts besseres als eine grüne Ampel.
(Ok, dass ist gelogen. Die Ampel sollte bei TTD ja nur beim Commit grün sein, ansonsten immer rot. Den das Rot erinnert einen deutlich was als nächstes gemacht werden soll.)

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

TDD ist ein interessantes Konzept, und ich folge dem manchmal. Oft mach ich’s aber doch wieder andersherum (erst Code, dann Tests), da ich meist die Interfaces noch nicht genau genug im Kopf habe (Funktionsnamen variieren gerne z.B.) um von vornherein unveränderliche Tests zu schreiben.

Tests werden aber für neuen Code bei mir oft sofort geschrieben. Sonst lässt man’s nur schleifen und wir wissen alle wo das endet …

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Auf der Arbeit habe ich sehr viel mit Legacy-Code zu tun, aber wenn ich neuen Code entwickle, dann immer mit Tests im Hinterkopf. Und wenn es die Zeit zulässt gibts dann auch Unit-tests dafür, was leider selten der Fall ist.

Wichtiger finde ich beim Thema "sauberes Programmieren" aber eine gute Doku. Dazu habe ich Jenkins so eingerichtet dass er automatisiert nach einem SVN-Checkin (ja, auf der Arbeit nutzen wir noch SVN, privat bevorzuge ich GIT ) mti Doxygen, pas2dox und GraphViz eine Codedoku generiert. Bisher wurde nur auf die "alte Weise" kommentiert, also irgendwo // in den Code wenn der Entwickler der Meinung war der Code müsse erklärt werden. Für neuen Code. bzw. Code den ich refactore nutze ich jetzt aber immer XMLDoc, der dann in die Quellcodedokumentation einfließt.

Und auch das Thema Refactoring sehe ich grade in Bereichen mit viel Legacycode sehr kritisch. Wenn ich Legacy Code bearbeiten muss, dann wäge ich i.d.R. (wenn die Zeit es zulässt) ab ob es zeitlich hinhaut den Code zu refactoren und so aufzusplitten dass er mit Unit-Tests versehen werden kann.

Aber wie i0n0s schon sagt. Wenn man nur neuen Code schreib ist das alles schön, bei mehreren Millionen Zeilen Legacy-Code wird man dann aber nur eine sehr geringe Testabdeckung bekommen und Regression kaum verhindern können.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich schreibe eine technische Anwendung, wo der wichtige Teile ohne Tests gar nicht denkbar wäre. Die Methoden müssen quasi alle kleinteilig getestet werden, da man das Gesamtergebnis eigentlich gar nicht mehr nachvollziehen, geschweigen denn testen könnte.
Das Vorgehen, erst einen Test zu schreiben und dann den Quelllcode, halte ich persönlich für sehr theoretisch. TDD ist für mich schon, wenn Tests und Code sehr dicht voneinander abhängig sind. Und das hängt sicher auch von der Art und Thematik des Programmes ab.

Naja bei manchen Kunden kann man das echt nicht platzieren. Gerade bei solchen Experten die alle paar Tage mit nen Change daher kommen, kann so etwas echt hinderlich sein. Aber ja man sollte sich so früh wie möglich darüber Gedanken machen

_________________
Meine Homepage

Ich hab mich öfter mal dazu überreden lassen mir TDD anzuschauen. In der Uni wurde es uns in einigen Projekten auch aufgezwungen. Aber irgendwie bin ich nie richtig warm damit geworden. Ich sehe durchaus die Vorteile von TDD aber ich habe persönlich Probleme mit der Arbeitsweise. Für wahrscheinlich 50% des codes eines großen Projektes schreibt man triviale Tests die, obwohl genau so wichtig wie andere Tests, einfach mal nur geschätzt 1% der Fehler verhindern. Man schreibt also viel code der am Ende nichts bringt. Auf der anderen Seite gibt es aber auch code dessen tests einen hohen Aufwand erfordern … sei es nur manuell erwartete ergebnisse zu erstellen und diese dann mit der implementation zu vergleichen.

Weiterhin habe ich große Probleme damit Interfaces vorweg zu planen. Und auch Änderungen an Interfaces werden einem meiner Meinung nach unnötig schwer gemacht durch tests, die dann auch wieder auf die Änderungen angepasst werden müssen. Wenn ich an einem neuen System arbeite bin ich manchmal einen Tag nur damit beschäftigt dummy-code für alle nötigen Klassen zu schreiben weil mein Verständnis der Klassen erst mit dem Schreiben kommt und deswegen die Interfaces anfangs ständig angepasst werden.

Der Hauptgrund warum ich mich damit wohl noch nicht anfreunden konnte ist aber wohl, dass ich zu faul bin diesen (teilweise sehr hohen) Aufwand zu betreiben um hauptsächlich Flüchtigkeitsfehler zu finden.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Test driven development und Spieleindustrie sind wie Sonne und Wasser; es kommt zur Explosion, wenn die sich zu nahe kommen.
Tatsächlich kann man froh sein, wenn man mal Zeit hat sein Code grob zu debuggen an Tests schreiben ist garnicht zu denken.

Ich selber hab mal TDD für 2-3 Klassen im Radon Framework praktiziert aber ich schreibe lieber erst den Code und dann schreibe ich die Tests und korrigiere dann mein Code.
TDD kostet meiner Erfahrung nach mehr Zeit, wenn man erst die Tests schreibt und dann die Implementierung macht als wenn man die komplette Implementierung macht und dann die Test schreibt. Das liegt bei mir daran, dass ich zwischendruch das Design änder, wenn ich Optimierungen oder Konzeptprobleme finde. Die Tests, die dann weg fallen waren verschwendete Zeit im großen gesammt Bild.
Ich habe dann auch gleich eine Code Review, weil ich mir ja jeden Namen, jeden Branch, jeden Call angucke und wie der Programmfluss ist und so noch bessere Lösungen von Zeit zu Zeit finde.

Ich bin ein Fan von TDD, weil man auf lange sicht Zeit spart und schneller Fehler findet aber auf kurzen Entwicklungszeiten ist es kontraproduktiv.
Ein Spiel was nicht fertig ist kann nicht geshipped werden aber ein Spiel was fertig ist und bugs hat kann man shippen.
Spieler haben eine akzeptanz zu Bugs, wenn sie eine Schwelle nicht überschreiten und je früher ein Spiel raus kommt, des so weniger ist das Risiko für Verluste.
Gerade in meiner Branche zählt jeder Tag, den man früher shippen kann, weil so ein Team sehr viel Geld kostet und das Geld über Jahre wieder eingespielt wird. Da gibt es ein Unterschied zwischen Boxed Games, wo schon Pre-Order durch Spieler und Verkäufer, wie z.B. Media Markt Geld rein gespült wird oder Micro Transaction, wo man erst anfängt Geld zu machen, wenn das Spiel Online ist und selbst dann baut sich erst über Monate eine zahlende Userschaft auf.

In mein Framework hab ich aktuell nur 6-7 Klassen mit Tests und das sind schon ~280.
Davon sind mit dem aktuell laufendem refactoring meiner String Klasse gut 40 broken.
Ich gehe die Stück für Stück durch, korrigiere und mach dann wieder weiter.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Koennt euch ja mal das Konzept der join-points und AOP reinziehen. Das Zeug ist quasi Dummy-Proof fuer Geschichten wie TDD. Ausserdem zwingt es einen mal dazu den typischen OOP-Fehler zu vermeiden. Sprich man betrachtet Objekte mal nicht nur im Sinne von Kapselung sondern auch als Prozess.

_________________
Meine Homepage

Also für die Leute mit Legacy Code gibt es dieses Video was ich seeeeehr empfehle (insbesondere Java-Leuten): https://www.youtube.com/watch?v=_NnElPO5BU0

Ansonsten bin ich erfreut über die Ehrlichkeit der Antworten und der Gründe warum man es nicht machen kann. Klingt nach dem WhoIsWho/Top10 der Ausr...Erklärungen wieso TDD nicht angewendet werden kann.
Hab ich in meinem Projekt auch.

Ich hab die letzten 6Tage (FTE) damit zugebracht ein Stück Quellcode, welches ich nicht refactoren konnte auf Grund seiner Vertracktheit neu zu schreiben. Ich hab diesmal TDD durchgezogen und es war ein Augenöffner. Ja man verwendet 50% der Zeit auf die Tests. Aber der Code sieht anders aus. Man refactored den Code regelmäßig und zieht Klassen raus, was man sonst niemals machen würde ("Die paar Zeilen, das lohnt sich nicht") was einem aber einen massiven Boost in Sachen Testbarkeit gibt.
Ich hab plötzlich begriffen, wieso eine Factory die nicht weiter als new Xyz aufzurufen, einen Mehrwert bieten kann.
Wenn man aus Testsicht seine API schreibt, dann schreibt man sie gleichzeitig aus Sicht eines Clients/Nutzers. Dadurch sind die Schnittstellen im Schnitt besser wiederverwendbar und stabiler.

Und wenn man es wirklich knall hart durch zieht, ist die Testsuite sogar die Dokumentation - eine Ausführbare Dokumentation welche zwingend die Wahrheit sagt. (Außer Vollpfosten ändern die Tests (anstatt den Code) weil die Rot waren.... alles schon gesehen....)

Wer etwas zeit hat kann sich diese Video mal reinziehen (Mit sowas schlag ich mir die WE um die Ohren....):
https://www.youtube.com/watch?v=1ppouZ-x-oY (Roy Osherove on Unit Testing Worst Practices at Bouvet.no breakfest - YouTube)
https://www.youtube.com/watch?v=HZJxjlvBbVA (Clean Code - YouTube)
http://www.youtube.com/watch?v=HhwElTL-mdI (Test-driven development: Write better code in less time by Evan Dorn - YouTube)
https://www.youtube.com/watch?v=RAxiiRPHS9k (Fast Test, Slow Test - YouTube)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Diese Erfahrung hatte ich auch gemacht und bin froh, dass ich nun nicht mehr Demos und so pflegen muss, die Unit Test zeigen einfach alles auf, was geht und ich guck auch gerne in Unit Tests von OpenSource libs, statt in die Examples.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich hab mal das erste video im Hintergrund laufen lassen und das hat nix gebracht, da muss man aktiv zu gucken :\
Mal gucken das ich die Video runter lade und auf iPad in der Bahn gucke.

Ich hab gesehen, dass mein Visual Studio 2013 Ultimate auch Runtime Test für C++ drin hat aber ich hab mich damit noch nicht groß mit beschäftigt. Ich hab mal versucht ein Test zu bauen aber das ist komplett Managed Syntax in C# like Class und Method Attribute Syntax und das kommt mir nicht in die Tüte. Mal schauen ob man auch externe Task triggern kann.
Meine Unit Test sind mit mein eigenen Unit Test Suite geschrieben und geben JUnit output raus, mit den Unterschied, dass die Zeiten nicht in Sekunden sondern Microsekunden ausgeben werden und man kann bis auf Test Ebene granulieren was ausgeführt werden soll.
Die Änderung in der Zeit hab ich gemacht, weil ich neben den Unit Tests noch Performance und Resource Tests hab und die Performance Tests laufen 5 mal die gleiche Routine durch und brauchen natürlich nur extrem wenig Zeit, so das ich dank der JUnit Specs immer 0 Sekunden raus bekam(die haben die Nachkommastellen beschränkt -_-).
Mein Jenkins gibt mir dann tolle Tabellen, was schneller und langsamer zu Vorversionen ist.
Alle Arten von Test sind noch ausbaufähig ^^

Ich hab gesehen, dass einige https://travis-ci.org/ an ihre GitHub Projekte angebunden haben, um die Unit Tests laufen zu lassen aber halt nur Linux :\

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich hab vor Kurzem auch Jenkins bei uns als CI "eingeführt" (ist sehr viel Legacy-Kram, bis es komplett genutzt wird dauerts wohl noch :/), das läuft auch unter Windows. Und (mit viel Mühe) auch mit Delphi und DUnit für die Unit-tests, inkl. Plugin (XUnit) dass die DUnit-Testlogs auswertet und die Builds dann ggf. als isntabil markiert.

Richtig geil wenn man sowas automatisiert sieht Irgendwo checkt jemand ein, Jenkins checkt automatisch aus, kompiliert, lässt die Unittests laufen, erzeugt Projektdoku via Jenkins und informiert mich dann per Mail wenn der Build fehlschlägt oder instabil wird.

Leider haben wir noch zu geschätzt 98% Legacy-Code, und die meisten Entwickler tun sich schwer TDD (oder Refactoring, oder irgendwas modernes) zu nutzen. Wird also ein langer Weg.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab wie in meinem Projekt Thread schon mal beschrieben ein Buildgrid mit Jenkins Zuhause.
Da sobald ich ein Commit auf meiner Kiste mache, versucht der erstmal Jenkins an zu rufen und ein vollständigen Bau, Testen, Code Analayse, Code Coverage auf diversen VM's zu machen.
Leider kostet der Server ziemlich viel Strom(8kern, 16GB Ram, 8TB RAID 10) daher ist der nicht so häufig ab ^^
Die Lösung wäre eine LAN Steckdose oder WakeOnLan zu verwenden aber 2. hat bei mir nie funktioniert.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

@Sascha: ich fühle mit dir. Aber du machst das schon richtig, d.h. du gehst als Vorbild vorran. Das ist die einzigste Chance die man hat, wenn man keine Weisungsbefugnis hat. (Siehe Sharma, leader without a title)

_________________
Blog: kevin-fleischer.de und fbaingermany.com