Ich entwickle Software seit über 30 Jahren. Tests halte ich für wichtig, aber ja definitiv idR. ziehe ich die nach. Es gibt Ausnahmen - wie du schon sagst, wenn man was gut versteht. Da macht es dann Spaß Test für Test grün zu machen. Ich habe letztens einen Parser geschrieben - die Sprache war 100% definiert. In dem Szenario hat TDD Sinn ergeben. Das Wichtigste bei mir ist, dass ich für jeden Fehler der gefunden wird einen Unit Test nachzieht. Damit man dann später keine Regressions hat. Tests sind Werkzeuge und keine Religion.
Vielen Dank für diese Ausführung. Ich finde es immer wieder erstaunlich: Themen die mir durch den Kopf gehen bei denen ich mit nicht ganz sicher bin werden in vielen Eurer Videos durchgenommen und bestätigen meine Gedanken dazu. Mit diesem Video ist es genauso, mir kam TDD auch oft hinderlich vor (aus den genannten Gründen) und nach längerem Gedanken machen und "verstehen" zeigte sich oft dass das vermeintliche Problem gar kein Problem ist. Vielen Dank für Eure bisherigen Videos und für alles was kommen wird.
Auch beim Test-Code gilt DRY. Ich verwende deshalb (im Test-File) oft eine kleine Funktion zur Instanz-Erzeugung, ebenso kleine Wrapper-Funktionen für den Aufruf der zu testenden Operationen. Bei einer nachträglichen Änderung an der Signatur der zu testenden Methoden, brauche ich nur die Wrapper-Funktionen anzupassen. Der Code zum Aufruf einer Wrapper-Funktion ist auch oft kürzer als der Code zum direkten Aufruf der zu testenden Operation.
Der Fachbegriff fuer die im Video beschriebene Vorgehensweise lautet uebrigens "Spike and Stabilize". Ein Spike ist ein oft von vornherein zeitbegrenzter Wegwerf-Prototyp um wie erwaehnt ein Gefuehl fuer das Problem zu bekommen und verschiedene Ideen auszuprobieren. Wenn der Spike erfolgreich war, muss man ihn stabilisieren und darf ihn nicht einfach als Endprodukt behandeln. Das kann entweder durch Neuschreiben oder durch Refactoring geschehen.
Um deine Eingangsfrage zu beantworten, Golo: Ich habe diese Video angeklickt, weil ich deinen Ausführungen unglaublich gerne lausche und immer etwas daraus mitnehmen kann. Dass mich das Thema zusätzlich noch interessiert, ist nur das Sahnehäubchen. 😁 Auf diesem Weg also mal ein riesiges Dankeschön für deinen Dienst an der Entwickler-Community. 👍
Im "Originalbuch" des TDD wird das als "Explorative Coding" bezeichnet. Der Autor verkauft dort das TDD als ein Werkzeug das sich an das notwendige Sicherheitsbedürfnis (notwendiges Confidence Level) anpasst. Er verweißt aber immer wieder darauf, dass man tendenziell lieber etwas zu vorsichtig ist als umgekehrt. Das ist vor allem für Anfänger im TDD ein großes Problem. Man überschätzt sich ständig und nimmt in dem Zuge ggf. aus diesem Video die falsche Botschaft mit. Dass man die Public API des zu Testenden Codes ständig ändert ist oft auch ein Hinweiß, dass man das Problem nicht weit genug zerlegt. Die Testfälle sind also zu komplex, das System ist nicht modular genug und das merkt man daran, dass man immer wieder viele Testfälle gleichzeitig anpassen muss. Es spricht auch nichts dagegen, code den man eigentlich nur zum testen braucht selbst unter Testkontrolle zu stellen, wenn dieser eine gewisse komplexität erreicht. Als Programmierer, das sich sein leben lang sein Hirn an fast unlösbaren Problemen zermartert hat und die Bestie mit bösen hacks gezähmt hat, ist die TDD Welt nach einer kurzen Zeit bereits so paradisisch, dass man oft den Weg nicht bis zu ende geht, weil man sich einfach nicht vorstellen kann, dass es noch einfacher und noch besser werden kann. Man fühlt sich bisweilen von der trivialität unterfordert und denkt, ach das geht auch so. TDD braucht einfach Zeit zum erlernen sodass man die ganzen schlechten Angewohnheiten ablegen kann, die man schon garnicht mehr in Frage stellt. Es ist einfach eine ganz andere Art zu programmieren.
Es gibt noch eine dritte Möglichkeit warum ich mir das anhöre: weil es von dir ist und ich finde du machst das ausgezeichnet! Du lieferst sehr interessant Inhalte sehr pointiert, kurzweilig und informativ. Danke für deine Mühe - freue mich schon auf Weiteres! 😊
Schönes Video, ich würde ein wenig ergänzen: - Unit Tests geben einen Entwickler auch ein Gefühl oder Hinweis, wie etwas zu implementieren ist. Oft bemerke ich, dass noch eine Klasse oder ähnliches fehlt. Unit Test fördert klar das Schreiben kleiner Klassen (SRP). - Selten habe ich den vollständigen Blick, was ich alles benötige für eine Anforderung. Eine gute und vollständige Anforderung benötigt einen guten Vermittler von Anwender zu Entwickler. Der Vermittler muss dann auch Test + Daten stellen. Fehlt der wird es schwieriger bei der Umsetzung. Dann sind Unit Tests noch wichtiger, weil man ggfs oft den Code umstellen wird. - Was auch passieren kann, dass man zuerst die externen Komponenten ausprobieren will. Da bietet sich ein POC eh an. - Gerade Randbedingungen bei Tests fallen mir zum Teil 1 oder 2 Tage nach der Implementierung ein. Aber zum Teil war ich auch mathematischer bzw algorithmischer Unterwegs (NP Probleme, geometrische Algorithmen usw). - Unit Tests sind zum zeigen, wie Code angesprochen werden kann. Gar nicht schlecht für jemanden, der dagegen Programmieren soll. Zumindest hat man ein kleines Beispiel, welches man auch zusammen debuggen kann. - Jeder Fehler, der durch Tickets reinkommt, kann man meist recht einfach mit einem Unit Test abbilden. Was ein riesiger Vorteil ist, wenn man gut loggt, zum Beispiel die Übergabeparameter als JSON loggt oder ähnliches. - Bei Erweiterungen am Bestandscode kann ich zumindest sicher sein, dass Bestandstest immer noch laufen und somit altes Verhalten gewährleistet wird. Ohne Tests wird irgendwann an Bestandscode wenig oder gar nicht mehr angepasst und wenn dann nur, wenn es sein muss. Aus Erfahrung würde ich meinen, dass man mit Test locker 80-90% der üblichen Fehler vermeidet, die einem sonst auf die Füße fallen würden. Alleine das ist der Grund Tests zu schreiben. Weniger stress Fehler schnell zu beseitigen, weniger unerwartete Tickets, mehr Zeit für eigene Entwicklungen, weniger Zeit für integrative Tests vergeuden. Das sind nur wenige Punkte, die es eigentlich unabdingbar machen.
Richtig, erst muss man das Problem in die algorithmische Ebene bringen, das ist eine Denkleistung welche einem von Tests prinzipiell nicht abgenommen werden kann. Sobald man aber einen Lösungsansatz zur algorithmischen Dekomposition der Aufgabe hat, kann man diesen durchaus mit TDD entwerfen, um eine Struktur reinzubekommen, und früh an die Designfehler aufmerksam zu werden.
Da ich mal das programmieren mit Eiffel unglaublich heftig gemacht und geliebt habe. Gehe ich einen anderen Weg der leider nur in Eiffel perfekt war. Man nutzt die Tests um die Szenarien die später benutzt werden ablaufen zu lassen, man schreibt aber keine REQUIRE tests gleich am Anfang. Damit kann man erstmal interaktiv loslegen zu entwickeln und auszuprobieren. Die korrektheit wird dann nicht in den Tests sondern durch Design By Contract erledigt, das heisst man schreibt sehr sehr viele assert statements an allen Punkten. Und fuer einige Dinge dann verpackt in Algorithmen, z.B. eine besondere "equals" Funktion die man dann einsetzen kann um nach jedem ein Undo/Redo zu testen. D.h. vieles wandert vom Test in den algorithmischen funktionalen Teil und der wird wie der Code inkrementell entwickelt und nicht am Anfang. Erst am Ende von Version 1 oder sogar Version 2 fuegt man dann Endtests ein fuer ein spaeteres groesseres Refaktoring und bevor man sein Kleinhirn von den Details wieder leert um mit etwas anderes zu machen. Hinweis: Ich habe mit 14 angefangen zu coden und das ist jetzt 40 Jahre her. Professioneller Software Entwickler im nicht Web Bereich.
Ja, Eiffel ist an der Stelle superdurchdacht, auch wenn ich DbC nur in anderen Sprachen angewendet habe, Ich habe mit Invarianten schon sehr knifflige Sachen entdeckt auf die ich sonst nicht gekommen wäre (wenn z.B. Kollegen unbedacht Datenbank-Constraints ausgeknipst oder Datenbankeinstellungen wie Encoding oder Genauigkeiten verändert haben…).
Ich habe das Video jetzt 42 Sekunden angeschaut und mich hat Grund Nr. 2 getriggert :D Edit: Wirklich gut erklärt. Ich habe mir Disziplin antrainiert, nachdem ich paar mal an wirklich schlimmen Code mitarbeiten musste. Beim Programmieren wird oft und viel Code gelesen, statt geschrieben und wenn man den Code nicht mehr lesen kann, wird die Arbeit zur Qual. Es ist einfach ein Unterschied ob du nach einer halben Stunde, dich in einer fremden Software schon orientrieren kannst, oder auch nach einem Jahr immer noch nicht in der Software durchsiehst. Hatte ich nämlich beides und gehe notfalls auch auf konfrontation. Das Motzen hat mir auch Jobs gekostet, aber danach musste ich mich damit wenigsten nicht mehr rum ärgern.
[gr] Haha 😊 Und zu Deinem zweiten Absatz: Danke schön! Und ja, klar will man nicht immer die Übelkrähe sein, aber letztlich hilft es ja nichts (vor allem einem selbst am allerwenigsten), wenn man unzufrieden ist.
Du hast mich mit dem WebAssembly Video gepackt und nun verfolge ich auch deine anderen Videos. Wirklich gute Ausführungen, danke. Ich bin seit 6 Jahren Vollzeit-Entwickler und kann dem nur zustimmen. Die meisten Probleme, die ich sehe, sind neue Probleme. Vorab schon zu wissen, wie meine Lösung aussieht, erlahmt mich unglaublich, und es macht auch keinen Spaß. Stattdessen macht es mir großen Spaß meinen zuerst geschrieben Code mit Tests abzudecken, und dann diesen zu refactoren, weil man dann genau sieht, wo die Schwachstellen sind. Ein Wegschmeißen habe ich noch nicht probiert, ist aber ein spannender Ansatz. Und ja, ich würde sagen, rund 80% des Aufwands, ist es das Problem richtig zu verstehen.
[gr] Danke schön 😊 Vor allem: Wenn es bereits ein bekanntes Problem mit einer bekannten Lösung ist - wieso entwickle ich das dann neu? Das könnte man dann ja eventuell auch einfach kopieren 😉 Das mit dem Wegwerfen ist tatsächlich ein spannender Ansatz. Vielleicht machen wir dazu noch mal ein Video, in dem wir zeigen, wie wir an eine Komponente herangehen.
Ich persönlich habe schnell genau diese Erfahrung gemacht. Zum Glück habe ich bei meinem letzten Arbeitgeber die volle Ladung input zu TDD bekommen. Was nicht bedeutet hat dass ich am Ende TDD entwickelt habe - aber dennoch meine letzten projekte mit >90% test-abdeckung abgegeben habe. Ich konnte einfach nicht auf die art und weise denken "vom test zum code" und zugleich im blick behalten wie ich das Problem (eigentlich in dem Fall Features) lösen kann. Denn der Weg zum fertig entwickelten Feature ist einfach häufig kein gerader weg. Man kann sich häufig weder von Top-to-bottom noch umgekehrt geradewegs durcharbeiten. So geht es mir zumindest. Ich behalte im Blick, dass die Klassen klein genug sind und die Architektur stimmig und offen ist. Bis man da angekommen ist dauert es etwas und in der Zeit kann ich und will ich für etwas das noch nicht stehen bleiben kann tests entwickeln.
@@thenativeweb jetzt habe ich mal die vielen guten Diskussionen (oft mehr als nur Kommentare) gelesen. Dieser frühe Kommentar gefällt mir auch gut, weil er eine wichtige Frage aufwirft, die hier wenig angesprochen wurde: Wer sollte einen Test schreiben? Wenn es die "technische Dokumentation einer Anforderung" ist, könnte/sollte doch der Product Owner diese Test schreiben - oder jemand, der die Sicht des Produkt-Owners spezifizieren/konkretisieren will, was ja auch ein Entwickler sein kann, der anschließend die Implementierung angeht und durch das Test schreiben sicher stellen will, den Product Owner richtig verstanden zu haben. Insofern sollten "Tests" doch die Dialogsprache zwischen Product Owner und Developer sein. Ein Product Owner muss ja die Implementierung nicht verstehen (black box) - aber das Verhalten ist die domain des Product Owners.
[gr] Das ist richtig, das setzt aber letztlich voraus, dass auch der Product Owner zumindest soweit programmieren kann, dass sie beziehungsweise er die Tests formulieren kann. Oder man verwendet ein Konstrukt wie Gerkin und BDD, wobei ich noch nie in der Praxis gesehen habe, dass es wirklich gut funktioniert hat. In der Regel funktioniert das nicht ohne Entwickler, aber vielleicht habe ich dafür auch einfach nur die falschen Beispiele gesehen.
@@martinhovekamp8315 Die wörtliche Dokumentation der Anforderungen wird doch auch von den Entwicklern des System geschrieben, und dann dem Kunden gezeigt und abgeglichen ob man nun verstanden hat was der will. Bei den Tests könnte es ähnlich laufen. Und wenn man die Sprache des Kunden ("ubiquitous language") verwendet, müsste er sich in einer guten API quasi wie von allein zurecht finden - zumindest auf der obersten Abstraktionsebene.
Vielen Dank und meinen höchsten Respekt für deine Sichtweise und deine Art es zu vermitteln. Ich selbst höre auch immer wieder hitzköpfige Vorgesetzte die gern alles und jeden in TDD arbeiten lassen würden und viele Entwickler die denken Testen sei etwas für Entwickler die nicht wüssten was sie tun. Meist macht deren Arbeit aber eher den Eindruck als wüssten sie das selbst nicht. Wirklich oberster Punkt ist dass man seinen Code testbar schreibt. Das KANN man meiner Meinung nach durch TDD lernen, wichtiger ist aber sich und seine Arbeit immer wieder zu hinterfragen, bei den Tests nicht darauf zu achten, dass die Abdeckung erreicht ist und jede Zeile in der IDE irgendwie grün wird sondern das man die Tests als eine Art Dokumentation des Codes sieht und auch so versteht. So lernt man bessere Tests zu schreiben und merkt auch mehr und mehr, meiner Meinung nach, wo es beim Code noch klemmt bzw. was man eleganter Lösen sollte. TDD ist wie OOP und andere Paradigmen. Es gibt leider viele Fanatiker die nur hören "ich finde es scheiße, wenn ich es nicht gut finde", aber sie denken nicht darüber nach, WARUM es so ist, wollen es meist nicht einmal hören. Du hast erst ein Video gemacht (bzw. habe ich es jetzt erst gesehen) zum Thema Design Patterns. Dort hast du es eben so gut erklärt, es gibt kein Gut und Schlecht hinter Techniken. Es ist immer der Anspruch des Entwicklers der es optimal einsetzt oder es übertreibt. Keine Technik ist per se schlimm. Es ist immer das Maß und vor allem das Mögliche im Vergleich zum Notwendigen. Danke dass du deine Anspruch mit der Welt teilst. Ich wünschte mir viel mehr Menschen wie dich in der Welt der Entwickler. Dann wären nicht so viele Projekte so grottig und zum scheitern verurteilt, wenn sie eine Renaissance erfahren sollen. Es wäre nur wünschenswert, Entwickler mit weitaus weniger als deinem Anspruch würden deine Videos sehen und vor allem Verstehen und beherzigen! Es ist immer schön zu wissen, dass es mehr Menschen mit Anspruch gibt, als "nur" mein Team ;)
@@thenativeweb Nicht dafür. Ich danke dir für deine Anspruch und deine Qualität. Sehr selten und so extrem wichtig. Ich freue mich über jeden, der so über diese wunderbare Arbeit denkt und damit umgeht.
Eine Best Practice die hilft Tests bei Refactoring nicht exzessiv umschreiben zu muessen ist, nur oeffentliches (public) Verhalten zu testen. D.h. nicht testen WIE etwas intern implementiert ist, sondern nur das der Code das richtige nach aussen hin tut. Refactoring hat ja das Ziel, die interne Code-Struktur oder Performance zu verbessern ohne das externe Verhalten des Codes (was durch Tests validiert wird) zu veraendern.
[gr] Das ist richtig: Tests sollten auch für mein Verständnis Blackbox-Tests sein, die nicht von der internen Implementierung abhängen dürfen. Tests sollen Verhalten und nicht Implementierung testen. Leider schützt das trotzdem nur bedingt vor dem Problem, größer umschreiben zu müssen, dann nämlich, wenn die Public-API zu Beginn unpassend entworfen wurde. Einfaches Beispiel: Nach ein paar Stunden stellt man fest, dass man zum Beispiel lieber Tag, Monat und Jahr einzeln statt als Date-Objekt übergeben will, oder man stellt fest, dass ein bestimmter Parameter unnötig ist, oder oder oder … Das ändert aber nichts an der Relevanz und Korrektheit Deiner Aussage: Tests sollten stets nur von Außen testen, ohne Kenntnis des Inneren.
Großartiges Video! Ich würde sogar noch weiter gehen und sagen, dass 100% Abdeckung unnötig sind, wenn man erfahren genug ist. Ich beziehe in die Bewertung, ob ein Test notwendig ist immer folgend Kriterien ein - Aufwand des Testens (je niedriger desto test) - Wahrscheinlichkeit des Fails (je höher desto test) - Stärke der Auswirkung eines Fails (je höher desto test) - Änderungshäufigkeit (je höher desto test) - Wichtigkeit des Codes (je höher desto test) - Komplexität eines äquivalenten manuellen tests (je höher desto test) Nach diesen Kriterien teste ich z. B. selten reine Ausgabeerzeugung (Rendering), aber z. B. immer (Restful)-APIs und utility-Funktionen
100% bekommt man in der Regel nur bei Stateless Systemen überhaupt hin. Dennoch ist es ein gutes Gefühl, wenn alle Branches in einer Funktion getestet sind. Wie oft habe ich schon Bugs in Exception Handlern gefunden…
@@stell4you Mir ist klar was TDD ist. Hast du das Video komplett angesehen? Mein Kommentar bezieht sich auf eine Aussage spaeter im Video und damit auch auf die Kernaussage des ganzen Videos.
hi, frage: ist nicht genau der prozess des herausfindens, was das problem ist, der eigentliche fokus des tdds? also das ständige hin und her zwischen test und code, was du als mühsam etc beschreibst. als "nebeneffekt" hat man dann halt hinterher auch eine gute testabdeckung und gut strukturierten code, gerade weil man sich halt im ständigen dialog zwischen test und eigentlichem code der lösung des problems auf methodische weise angenähert hat. also würde man hier doch tdd tatsächlich einen gewissen selbstzweck unterstellen können, im sinne einer methodik zumindest, oder? wenn ich mir zb das buch test driven by example oder das berühmte bowling-kata ansehe, das ja auch in "agile software development, ppp" von martin dargestellt wird, denke ich, dass hier die methodik sehr gut verdeutlicht wird. im "gegensatz" dazu wäre halt erst das problem lösen und danach tests schreiben eine option, aber dann ist es halt kein tdd. aber undogmatisch damit umgehen ist immer gut, finde ich. danke für die denkanstöße!
[gr] Das, was mich daran stört, ist, dass es sehr ineffizient ist. Gerade die Bowling-Kata (siehe codingdojo.org/kata/Bowling/) ist ein schönes Beispiel: Ich persönlich habe sie noch nie gemacht. Wenn ich sie machen würde, würde ich folgendermaßen vorgehen: - Problem auf Papier skizzieren und über Lösungsansätze nachdenken (wie gehe ich überhaupt vor) … dazu gehört auch, sich Datenstrukturen zu überlegen, und ähnliches. - Damit komme ich zu einer Annahme, wie ich es lösen könnte. Ich weiß aber nicht, ob das tatsächlich richtig ist. Bei trivialen Problemen mag das offensichtlich sein, bei komplexeren nicht. - Deshalb möchte ich als nächstes meine Annahme validieren. Das heißt, überprüfen, ob der von mir erdachte Ansatz überhaupt funktionieren kann, oder ob ich etwas essenzielles übersehen habe. Dazu schreibe ich das Ganze mal Quick'n'Dirty runter. - Erkenntnis in 99% der Fälle: Ich habe etwas übersehen und muss an meinem Konzept nacharbeiten. Das kann durchaus zwei, drei Iterationen brauchen. - Wenn ich das habe, dann weiß ich langsam auch, wie meine Signaturen aussehen, welche Funktionen ich überhaupt brauche, und es entwickelt sich ein Gefühl für die Frage, wie ich das ganze strukturieren kann. - Und dann werfe ich meinen experimentellen Code weg und schreibe es mit Tests neu, und das kann dann gerne auch nach TDD sein. Nur dieser eine letzte Schritt ist tatsächlich "Code schreiben" im Sinne von "die finale Lösung entwickeln". Alles davor ist Entwerfen, Validieren, Verstehen, Lernen. Dabei hilft mir persönlich TDD nicht, eher im Gegenteil. Vielleicht schreibe ich mir auch dafür schon mal ein paar Tests, aber nicht nach TDD. Weil das Ziel eben hier noch nicht ist, eine gute Struktur zu haben und die Funktionalität mit all ihren Spezialfällen zu überprüfen, sondern erst einmal nur, ein Bild von einer sinnvollen Vorgehensweise zu bekommen. Aber, wie gesagt: Das ist *meine* Vorgehensweise. Wer das von Vornherein nach TDD machen will, kann das ja gerne tun - nur *mir* wäre das zu aufwändig, weil ich TDD nicht als hilfreich empfinde, um die Lösung zu designen.
Ich finde den Abschnitt "Wann TDD keine gute Idee ist" nicht überzeugend. Aus mehreren Gründen: 1. Die Signatur einer Funktion braucht in den Tests nicht nachgezogen zu werden, denn die Tests testen ja einen Fall, in dem der Wert für den zusätzlichen Parameter immer gleich ist. Folglich bekommt der neue Parameter einfach einen Default-Wert, sodass er beim Aufruf der Funktion optional ist. 2. Wenn du das Problem als ganzes noch nicht verstanden hast, kannst du immer bei dem Teil des Problems anfangen, den du verstanden hast. Ein typisches Muster bei der Arbeit mit TDD ist, dass du das "eigentliche" erst ziemlich am Ende machst, d.h. bei einem Algorithmus fängst du mit der Abbruchbedingung an, dann nimmst du einen Fall der im Anschluss direkt zur Abbruchbedingung führt, etc. Ein Problem mit TDD bekommst du dann, wenn du in fragile Tests schreibst. Aber das lässt sich vermeiden, indem man von vornherein immer nur das (zukünftige) Facade-Objekt für einen Kontext testet und schrittweise eine Klassenstruktur hinter dieser Facade errichtet.
[gr] Ad 1: Dann habe ich unter Umständen einen Parameter, der testbedingt (!) optional ist, obwohl das aus fachlicher Sicht nicht sinnvoll ist. Abgesehen davon funktioniert der Ansatz mit optionalen Parametern spätestens dann nicht mehr, wenn man einen Parameter zum Beispiel semantisch ändert - beispielsweise Tag, Monat und Jahr als drei Argumente übergeben statt ein Date-Objekt. Das greift IMHO zu kurz. Ad 2: Klar kann ich dann mit dem kleinsten Teil anfangen, den ich schon verstanden habe - nur wenn sich dann im Lauf der Zeit herausstellt, dass ich das Pferd aus Unwissen von der falschen Seite aufgezäumt habe, habe ich trotzdem Tests geschrieben und unter Umständen eine Menge Zeit aufgewendet, für letztlich nichts. Daher bleibe ich dabei, dass ich es für sinnvoll erachte, zunächst mit einem Durchstich / Proof-of-Concept / Spike zu gucken, wie man das Problem lösen kann, bevor man es richtig löst. Frei nach dem Pretotyping-Motto: "Ensure that you do the right it before you do it right."
Ein schönes Beispiel, wie TDD bei schlecht verstandenen Problemen bzw. bei explorativem Programmieren schiefgehen kann, findet man, wenn man nach "sudoku tdd ravimohan" googelt.
8:55 Genau, nur bei den einfachsten Aufgaben ist es der Fall, daß man weiß wie die Lösung zu programmieren ist. Ein weiterer Einwand gegen TDD ist die Tatsache, daß es versucht (auch wenn ungewollt), den Entwickler zum Scheitern zu gewöhnen, was psychologisch nicht gut ist. Man fängt immer mit einem Test an, der fehlschlägt. Ein Vorgang wo man viel häufiger Scheitern erlebt als Erfolg ist entwicklerfeindlich.
Bei uns im Studium (ähnliche Zeit) wurde es zumindest mal erwähnt. Blieb aber abstrakt. Ich arbeite nicht mehr als Entwickler, habe mich aber irgendwann mal mit automatisierten Tests befasst und war beeindruckt. Was mich mal interessieren würde aus der Praxis: wie gut schafft man es, mit TDD alle Eventualitäten, die in Praxis vorkommen können, zu bedenken? Schon beim Beispiel IBAN-Validierung gibt es ja alle möglichen Fehlerquellen: zur lang, zu kurz, Leerstring, richtige Länge aber ungültig, unzulässige Zeichen etc. Schreibt man dann für alle einen Test?
[gr] Ja. Das ist natürlich viel Aufwand, aber … 😉 Angenommen, Du schreibst keinen automatisierten Test dafür, dann können diese Fälle ja trotzdem in der Praxis auftreten. Die Frage ist nur: Was passiert dann? Bestenfalls hat jemand vorher darüber nachgedacht, und fängt es ab. Aber wie? Ist das auf Dauer konsistent? Oder ändert jemand das irgendwann, oder baut einen Spezialfall ein und ändert damit die Semantik, was aber sonst niemand mitbekommt, weil es eben keinen Test gibt, der das abfängt und überprüft? Insofern ist der automatisierte Test kurzfristig mehr Aufwand, sorgt aber zum einen vor allem dafür, dass man sich mal fragt, welche Fehlerfälle es überhaupt alle geben kann, was zu expliziten Entscheidungen und nicht zu impliziten Annehmen führt, was den Code letztlich robuster macht, und zum anderen sorgt es dafür, dass es eine dokumentierte (denn Tests sind letztlich nichts anderes als automatisiert überprüfbare Design-Entscheidungen!) Entscheidung gibt.
In der Regel schreibst du einen Data-Driven Test, der als parameter dann eine IBAN (string) und eine erwartete Gültigkeit (bool) entgegennimmt. Je nach Sprache und Testframework kannst du dann recht einfach diverse IBANs an den Test übergeben. So musst du 1x die Testlogik (~10 Zeilen) und 20x mögliche IBANS mit Gültigkeit (1 Zeile jeweils) übergeben. Musst also um 20 IBANs zu prüfen nicht 10x20=200, sondern nur 10+20=30 Zeilen Code schreiben.
Ich habe sehr lange als C# Entwickler gearbeitet und dort immer automatische Unit-Tests geschrieben. Seit 2 Jahren arbeite ich jetzt primär als JS Entwickler und dort sind Unit-Tests eher die Ausnahme. Wir verwenden so gut wie keine Frameworks und fangen auch gerade erst an auf „Web Components“ umzustellen. Das größte Problem sehe ich im bootstrapping unsere Anwendung. Wie kann man so etwas effizient und einfach Testen?
[gr] Um ehrlich zu sein tue ich mir etwas schwer, Dir diese Frage zu beantworten. Was genau würdest Du denn testen wollen? Ich glaube, wenn Du das etwas näher einkreisen kannst, fällt es mir leichter, Dir eine sinnvolle und hilfreiche Antwort zu geben. Eventuell wäre das aber auch etwas für unseren Community-Discord - für den Link siehe Videobeschreibung.
Zu der Frage der Disziplin. Ich kann dem nur voll zustimmen, dass dies die Ursache vieler Probleme ist egal ob man TDD einsetzt oder erstmal nur Proof of Concept Code schreibt, aber oft liegt es auch einfach an der Firmenkultur wie mit Technical Debt umgegangen wird. Als Softwareentwickler steht man in vielen Firmen heute sehr unter Druck in kürzester Zeit Lösungen zu entwickeln und leider ist für langfristige gute Code Qualität oft keine Zeit. Ich glaube das liegt daran, dass in den Schlüsselpositionen der deutschen Industrie sich noch viele Personen tummeln, die von ihrem Mindset noch in der Ära der Wasserfallmodellentwicklung aufgewachsen sind wo testen halt erst ganz am Ende eingeplant ist und sowieso mehr als Zeitpuffer für alle möglichen Verzögerungen dienen musste. Auch wenn die aller meisten heute in kürzeren Entwicklungszyklen arbeiten und das auch bei den meisten Leuten in den Schlüsselpositionen angekommen ist, so wird dennoch Pair Programming und TDD als Zeitverschwendung angesehen.
@@Apenschi ich glaube ich kann mit Sarkasmus nicht umgehen, der Kommentar hat mich echt getriggert und ohne die ";-)" hätte ich komplett am Rad gedreht ^^ PP ist immer gut selbst wenn alle Entwickler sehr erfahren sind, allein für den knowledge transfer und auch um überhaupt wirklich "meaningful code reviews" machen zu können.
@@Apenschi mit "immer gut" meinte ich hier eher sowas wie oft von Vorteil ^^ Aber diese ganze Kosten Nutzen Analyse kann man gar nicht IMMER so gut machen ;-) weil man nicht weiß welcher Fundamental wichtige Knowledge Transfer durch Zufall bei einem PP Zustande kommen kann, der vielleicht dazu führt das man auf ganz neue Ideen kommt, die zu völlig neuen Geschäftszweigen führen und vielleicht zu einer Millionen schweren neuen Markterschließung führen. Das Argument mag zwar was weit hergeholt sein, ist aber so schon öfters so in Unternehmen passiert und in abgeschwächter form passiert sowas gar nicht mal so selten. Letztens noch mit einem Kollegen durch Zufall bei einer PP Session einen furchtbaren Bug gefunden, der dazu geführt hat, das bei einer seltenen aber nicht unmöglichen User Konfiguration ein Laser beim Beenden eines Prozesses nicht abgeschaltet wird. Für die Kosten Nutzen Rechnung hätten hier womöglich Menschenleben mit einbezogen werden müssen.
@@Apenschi ich kann verstehen wo deine eher realistische Perspektive auf PP herkommt, aber aus eigener Erfahrung muss ich sagen, dass es mittelfristig nur Vorteile bei mir bislang hatte und der Grund es sei zu teuer ein schlechter Grund ist. Man muss ja nicht gleich zwei Entwickler für 2 Wochen in einen Raum sperren um zusammen an einer Aufgabe zu arbeiten aber Mal eine 2h Session hat keine wirklichen Nachteile. Man schaut sich ja auch einen guten Arbeitstil und den ein oder anderen Trick beim anderen ab und dafür reichen auch kurze Sessions alle paar Wochen.
@@Apenschi Kann sehr gut sein, dass mir für eine allgemeingültigere Einschätzung einfach die Berufserfahrung fehlt und so wie du die Situation beschreibst ist das vermutlich auch schwierig mit PP. Ich würde aber dennoch mal versuchen eine naive allgemeingültige Aussage zu machen: Da wo Teams mehr code lesen als sie schreiben am Tag ist der Nutzen von PP größer als die Kosten. So wie ich PP verstanden habe, steht beim PP nicht im Vordergrund wie viel Prozent der Zeit bei einer Aufgabe zwei Leute wirklich zusammen vor einem Rechner Sitzen, sondern das sie eben nicht nur eine Code review zusammen machen, sondern wirklich zusammen herausfinden wie ein Problem gelöst werden kann und wirklich produktiver Code zusammen geschrieben wird und keine konventionelle Arbeitsteilung stattfindet. Eine klassische Review ist auch somit nicht mehr nötig, es sei denn noch eine dritte Person soll den Code überprüfen. Je nach Teamgröße und Art des Agilen (oder auch non-Agilen) Workflows sind ja zwei Reviewer Standard. Ich bin zwar nicht sonderlich zufrieden mit der Branche (Maschinenbau) in der ich derzeit als Softwareentwickler arbeite was so die Workflows angeht, aber ich möchte nicht in einer Branche arbeiten, wo mehr Code geschrieben als gelesen wird. Das Stelle ich mir dann schon ziemlich Oberflächlich vor, wenn sich keiner wirklich mit dem auseinandersetzt was andere tun. Oder alle sind so selbständig und schreiben so Agnostische Apis um ihre Komponenten, dass einfach alles funktioniert mit reiner blinder Verständigung. Das wiederum fänd ich enorm beeindruckend und die Tools um diese Entkopplung zu gestalten gibt es sicherlich (gRPC + protobuf oder Open Api oder sowas). Aber die größte Fehleinschätzung gegenüber PP ist sicherlich der Kosten Grund und dies liegt einfach daran wie die Arbeiteffizienz eines Softwareentwicklers bisher in der Industrie vor allem aus Human Ressource sicht gesehen wird. Das wäre nochmal eine ganz andere Diskussion.
@@Apenschi Kann ich nur zurück geben, ist ja selten genug geworden, dass man sich in den Kommentaren vernünftig unterhalten kann, wobei auf dem Channel hier echt nette Leute unterwegs sind.
Meine Herangehensweise ist, Forschungscode in einem Verzeichnis "playground" zu entwickeln. Verworfen werden gute Codeteile nicht. Sie werden einfach in die getestete Umgebung herausgezogen. Für ein Deployment dürfen keine Abhängigkeiten zum Playground mehr bestehen.
Mit TDD habe ich meine Schwierigkeiten, diese Methodik anzuwenden, wenn ich eine Software auf Basis einer Event-Driven Architecture entwickle. Da werden die Nachrichten ja mehr oder weniger mit fire-and-forget gefeuert und an sich kann ich da ja nat. kleine Teile testen, aber ein Systemtest als TDD wird da schon schwierig, finde ich. Grundsätzlich finde ich TDD aber gut und für die kleinen Teile verwende ich das (z.B. Aufbau der Domain), aber bei ganzen Architekturen habe ich es ggf. noch nicht verstanden.
Danke, kann vollständig unterschreiben. Und eventuell ergänzen. Es muss klar sein, in welchen Rahmen diese Entwicklung stattfindet. Wenn man eine bestimmte, aber unbekannte Domäne angeht, dann sammelt man erstmal Erfahrungen. Manchmal lange, manchmal nicht. Irgendwann wird man darin ein "Meister" bzw. eine/er mit sehr fundierten Erfahrungen. Doch. Wenn man soweit ist, wo ist die Garantie, dass man es weiter gestaltet oder es wird an die anderen weiter gereicht. Sind die Tests so was wie Wissenstransfer? Eine andere Sache. Wenn man Meister im den anderen Berufen beobachtet, dann stellt man fest, dass dort eine Zeit gearbeitet wird, danach nur 'aus dem Bauch heraus Entscheidungen ' getroffen werden. Egal ob beim Automechaniker, Chirurg oder dem Tattoo-Macher usw. Irgendwann kommt der Punkt, wo es einfach im Blut ist und die nächste Handlung oder Umsetzungsidee immer die richtige ist. Dann braucht man keine Tests mehr. Doch nur für sich. Daher, wenn ich meine eigene Projekte egal, ob in der Software-Entwicklung oder beim Hausbau, beim Schweißen oder beim Kochen durchführe - also da, wo ich schon Jahrzehnte an Erfahrungen habe - brauche ich keine Tests mehr.
[gr] Da bin ich fast bei Dir - der Unterschied zwischen den von Dir genannten Branchen und der Softwareentwicklung ist, dass zB das Schweißen oder das Operieren ein Produktionsprozess ist, die Softwareentwicklung aber eben ein Entwicklungsprozess. Das heißt, es geht bei der Softwareentwicklung viel häufiger um das explorative Erkunden von Neuem (wenn dem nicht so wäre, könnte man eine vorhandene Lösung ja einfach kopieren). Ein Hausbau läuft aber im Wesentlichen stets nach Schema F ab. Und das ist der Punkt, warum ich Tests trotz allem langfristig wichtig finde: Bei einem Hausbau änderst Du nicht mehr den Keller, weil Du beim Bau des zweiten Stockwerks feststellst, dass da was nicht passt. Das weißt Du vorher, wie Du sagst "aus Erfahrung", weil man es schon hundert Mal gemacht hat. Bei Software ist das anders. Da muss ich gegebenenfalls auch noch mal an das Fundament und das anpassen. Und da möchte ich dann schon gerne wissen, ob ich dadurch unbeabsichtigte Änderungen habe, beziehungsweise wenn ja, wo. Dabei helfen Tests dann enorm. Das heißt, für mich ist der Sinn von Tests weniger, zu zeigen, dass der Code *jetzt* funktioniert (da bin ich mir tatsächlich auch ohne Tests relativ sicher), sondern sicherzustellen, dass er es auch in der Zukunft tut, auch wenn größere Änderungen anfallen.
@@thenativeweb ich stimme dir jedoch nicht zu. Denn auch schweißen wird nicht unter den selben Bedingungen angewendet. Die Materialien, Form, Erreichungsgrad und vieles mehr - jedesmal was anderes. Daher. Es kommt auf die Erfahrung an. Auf die Meister Qualität. Genauso wie in der Entwicklung. Danke
Lädst du einen Teil deiner Videos eigt auch irgendwo (zB Spotify) als Wissenspodcast hoch? Gerade so ein Video in dem du nur redest und kein oder wenig relevantes Bildmaterial zeigst, wäre optimal ums beim Joggen oder Abends im Bett zu hören ❤
Es gibt mindestens zwei Voraussetzungen für den Einsatz von TDD: erstens, wie du es sagtest, man muss wissen, wo man hin will. Und zweitens: du musst deinen Chef davon überzeugen, geschätzt 20-30% mehr Entwicklungszeit einzuplanen und die ohnehin immer zu knapp bemessenen Deadlines über den Haufen zu werfen. Viel Spaß bei Punkt 2. :)
[gr] Die Frage ist, warum man das überhaupt diskutieren muss. Für mein Empfinden gehören Tests zum Sicherstellen der Qualität dazu, und das ist das, was von Kundenseite aus gefragt ist (Qualität). Natürlich zahlt kein Kunde explizit die Tests, aber bei dem, was Softwareentwicklung kostet, ist hohe Qualität praktisch nahezu immer erwünscht. Insofern würde ich die Frage gar nicht aufmachen, denn dann diskutiert man nicht über Qualität, sondern über die Werkzeuge. Tests zu schreiben sollte IMHO so wenig hinterfragt werden wie Kommentare oder Dokumentation zu schreiben. Natürlich kosten sie trotzdem Zeit. Die Frage ist: Wenn das 20-30% mehr sind als die ursprüngliche Schätzung - wo kommt diese Schätzung denn dann her?
Das Paradox von TDD: mehr Tipparbeit und spart trotzdem Entwicklungszeit. Wie geht das? Code eintippen macht nur 10% der Entwicklungszeit aus, 90% der Zeit verbringt man mit denken, debuggen, refaktorieren, etc. Durch TDD geht die Zeit fuer's Eintippen von 10 auf 15% hoch, weil man ja jetzt auch noch Tests schreiben muss. Aber die Zeit die noetig ist um zu debuggen, gruebeln, und auf den Code starren um zu verstehen warum genau er nicht funktioniert geht von 90% auf sagen wir mal 60% herunter. In der Summe sinkt die gesamte Entwicklungszeit dank TDD in diesem Beispiel von 100% auf 75%. Jeder Chef der Ahnung hat sollte daher darauf bestehen, das solide Entwicklungstechniken wie TDD verwendet werden. Weil das Geld spart.
Automatisiertes Testen spart im Vergleich zu manuellem Testen nach meiner persönlichen Einschätzung mindestens 50% der Zeit. Ob du die Tests zuerst schreibst oder nachziehst, macht dann keinen großen Unterschied. Man kann auch beim Nachziehen von Tests noch feststellen, dass der Code sich nicht gut testen lässt und ihn nochmal ändern. Und man kann auch ohne TDD nochmal refactorn, wenn schon alle Tests grün sind. Bei jedem neuen Feature, dass ich einbaue, gehen immer alte Tests kaputt. Die Mehrheit davon muss einfach nur leicht angepasst werden, weil der Test zu spezifisch war und nicht zum neuen Feature passt. Das mag vielleicht nervig sein, aber es geht immer sehr schnell. Aber die paar Tests, die rot sind, weil das neue Feature nicht korrekt verdrahtet wurde, sind einfach Gold wert.
@@kevingoslar7543 Wenn man sinnvoll testet und die notwendige Routine hat, dann hast du wohl recht. Wenn man die orthodoxe Lehre des TDD verfolgt und für jede Trivialfunktion erstmal einen Test schreibt, dann vermutlich nicht.
@@xtra9996 Du hast Recht, man benoetigt Erfahrung um TDD richtig zu machen. Und wenn man es wegen mangelnder Erfahrung zu mechanisch macht, kann es ineffizient werden. Das trifft aber auf so ziemlich alles zu und ist damit keine besonders treffende Kritik von TDD. Da es keine gesunde Alternative zu automatisiertem Testen gibt, ist TDD also eine notwendige Trainingsuebung fuer Entwickler und Teams die zu wenig Erfahrung mit Testen haben (meiner Ansicht nach immer noch 80-90% der Industrie). Der Weg zum Software-Ninja ist also: zu wenig und zu spaetes schreiben von Test (z.b. erst nach manuellem Testen) ---> strenges TDD ---> mehr nuancierte aber immer noch umfassende Nutzung von automatischen Tests. In jeglicher Form ist TDD meiner Erfahrung nach aber schneller und effizienter als zu wenige Tests und zu viel manuelles Testen und Debuggen.
Beim Studium kommt es auch immer darauf an, an welcher Einrichtung man studiert. Die allgemeine Universität hat nicht den Anspruch, eine Berufsausbildung darzustellen. Sie schafft lediglich die wissenschaftlichen Grundlagen auf akademischem Niveau. Da ist es nachvollziehbar, daß mathematische Beweise für einen Algorithmus Inhalt der Auseinandersetzung sind. Erwarten würde ich allenfalls eine analytische Untersuchung, was verschiedene Arten von Tests leisten können und was nicht, auch das wieder in wissenschaftlicher Herangehensweise. Die Praxis erwirbt man nach dem Studium oder parallel in Eigenregie.
CV ist ähnlich (12/40:). Themen im meinem Informatik-Studium (mit Nebenfach-Pflicht) waren völlig sinnlos. Nichts für bereits Praxis-Erfahrene. - TDD: Funktionen/ Methoden gehen nicht mehr über etliche Bildschirm-Seiten, haben nur noch wenige Zeilen und der Compiler warnt bereits während der Entwicklung sehr aktiv; und Beta-Tester kann es auch nicht ersetzen.
Kann mich deinen Ausführungen fast vollständig anschließen. Beim Prototyping braucht man tatsächlich Disziplin, geschriebenen Code wieder wegzuwerfen. Das ist nicht immer leicht. Wenn ich in einer derartigen Untersuchungsphase bin schreibe ich daher tatsächlich fast ausschließlich Test-Code und nichts im main. Ich nutze dabei die Tests selbst schlicht als Vehikel, um einzelne Komponenten und Ideen direkt ausführen zu können und bei Bedarf dann mit den bekannten Test-Werkzeugen aus dem Projekt auch mit Daten zu befeuern. Dadurch dass ich auch beim Prototyping nur Tests produziere, fällt es dann wieder recht leicht im Anschluss, diesen einfach wieder wegzuwerfen ;) Das Argument das ich am häufigsten höre, warum auf TDD verzichtet wird ist der erwartete hohe Aufwand. Ich bin der Meinung, dass wenn man TDD nur direkt auf APIs anwendet, sei es Framework APIs oder auch direkt REST-Endpoints, der Aufwand tatsächlich deutlich geringer ist, als wenn ich nach der eigentlichen Umsetzung erst mühsam die Tests implementiere. APIs kann ich i.d.R. innerhalb eines Projektes nämlich immer auf die gleiche Weise testen, was den Aufwand und die Wartbarkeit deutlich erhöht.
[gr] Ja, das stimmt. Was aber auch gerne vergessen wird, ist, dass der primäre Zweck der Tests gar nicht ist, die Korrektheit *jetzt* sicherzustellen, sondern *langfristig* dafür zu sorgen, dass man nicht aus Versehen etwas in seiner Semantik ändert, was man gar nicht ändern wollte … das ist aus meiner Sicht der viel, viel gravierendere Aspekt. Wobei man da noch mal genau zwischen TDD und Tests unterscheiden muss.
Eine kleine Zwischenfrage: Du sagst: “Für jede Zeile Code soll ein Test geschrieben werden.” Das meinst Du doch im übertragenen Sinne, richtig? Werden nicht eher Testfunktionen für einzelne Funktionen, Routinen und Classen (Objekte) geschrieben?
[gr] Jain … was ich meine, ist folgendes: Du sollst nicht für jede einzelne Zeile einen dedizierten Test bauen. Es darf (zumindest gemäß TDD) kein Code existieren, für den Du keinen Test brauchst. Also anders formuliert: Code sollte nur maximal das machen, was auch durch die Tests abgedeckt ist. Du solltest nicht schon eine Abkürzung oder einen Spezialfall irgendwo einbauen, für den Du noch keinen Test hast. Denn wenn Du das machst, dann hast Du Codezeilen, für die es keinen Test gibt. Und wenn Du dann an denen etwas änderst, beeinflusst das unter Umständen, wie sich Deine Funktion / Klasse / whatever verhält, ohne dass das über einen Test abgesichert wäre. Klarer?
@@thenativeweb Ja, so klingt das schon besser. Mir ging es eher um die Formulierung. Aber es geht auch darum, wie weit man das TDD treibt. Man kann neben den einzelnen Testfunktionen für einzelne Funktionen, Routinen usw auch noch eine weitere, übergeordnete Schicht an Testfunktionen schreiben, die die Zusammenarbeit der einzelnen Elemente testet, und dann noch eine weitere Schicht darüber. Wie auch die Aufrechterhaltung der Funktionalität bei gestressten Systemen.. usw, usw,...
Jetzt kommt wieder der Grünschnabel mit der absolut dümmsten Frage vermutlich =D Man schreibt den Test vor der eigentlichen Software?. Aber wenn ich doch garnicht weiss wie der Code aussehen wird wie dann eine Testumgebung schaffen ?
[gr] Das ist überhaupt keine dumme Frage - tatsächlich habe ich mich das vor Jahren auch gefragt. Und die Frage ist so essenziell, dass ich denke, dass es noch mehr Menschen gibt, die sich das fragen … und deshalb kommt demnächst ein Video zu dem Thema 😊
@@thenativeweb Ja Mega =P Vielen Dank dafür. Ich weiss nie wie mein Code vorher aussieht oder wie ich genau an ein Problem rangehen wenn ja noch nichts da ist. ich bin aufjedenfall gespannt =)
Eine weitere Sache warum TDD schwierig ist, du brauchst Erfahrenes Personal die a) das kennen und b) darauf bock haben. Da ja Tests of gar nicht oder kaum in Unternehmen zum Einsatz kommen geschweige den von TDD gibt es sehr viele Entwickler die es nicht kennen. Und wenn du einen Entwickler das aufzwingst worauf er persönlich keine Lust hat und es nur als Last ansieht, kommt auch am Ende das gleiche Resultat. Und ja TDD wird echt überbewertet wenn man das paar Jahre mal gemacht hat. Man kann es ja dann parallel mit CodeCatas üben. Ich habe so eine Pi mal Daumen Regel. Wenn du dir vorstellen kannst wie der Test dazu aussehen würde, reicht echt schon aus :D
[gr] Die Frage ist, ob wenn Tests gefordert werden, jemand sie aber grundsätzlich ablehnt, ob das dann die richtige Person für diese Aufgabe ist … wer es ablehnt, weil sie / er es nicht kennt, kein Problem: Das lässt sich ja lernen. Aber die Bereitschaft sollte schon da sein, sonst hat man ein anderes viel gravierenderes und tiefer liegendes Problem im Team als "keine Tests". Und was gerne vergessen wird bei den Tests: Der Sinn von Tests ist nicht (oder nur sehr bedingt), sicherzustellen, dass das, was man jetzt baut, auch funktioniert. Sondern sicherzustellen, dass der Code auch in der Zukunft noch funktioniert, nachdem Änderungen oder Erweiterungen vorgenommen worden sind. Quasi wie ein Sicherheitsnetz.
@@thenativeweb schon, aber ich kenne jetzt wenig Entwickler die sagen "Boah testen ist das beste was es gibt" dafür kenne ich Entwickler die mir dann eher sagen "Ich habe das ganze We verbracht das neue Framework zu lernen, es ist voll geil" Richtigen Personen ist eh bei unserem Beruf schwierig zu finden und wir müssen halt mit dem ARbeiten was wir die Resourcen her geben. Ich nutze gerne TDD sage nur dass es nicht einfach und manchmal kontraprodukt sein kann. Aber ich sehe total ein , mittlerweile ist es bei mir auch so dass ich den code danach messen kann ob ich dafür einfach tests schreiben kann oder nicht. TDD mach ich auch nur dann wenn ich vorher das Problem genau kenne.
Ich studiere momentan Informatik und da spielt automatisiertes Testen absolut keine Rolle. Generell kommt die Themen Code Strukturierung, Code Qualität und Software Architektur viel zu kurz.
Wo studiertest und was genau? Formale Verifikation sollte eigentlich immer noch Teil der Ausbildung sein. Unit-Tests lernt man sicher irgendwann an der FH.
Hi, ich habe deinen Kanal erst gefunden und finde, dass du das echt super machst. Freue mich auch schon auf diese Folge. Gehst du bei den Tests auch auf Programme wie Wallaby.js ein? Deine Meinung würde mich schon interessieren. Mach weiter so. Freu mich schon auf die Folge. Viele Grüße!
[gr] Vielen Dank, das freut mich 😊 Auf konkrete Tools gehe ich in diesem Fall nicht ein, es geht mehr um den konzeptionellen Ansatz. Was konkret Wallaby.js angeht, kann ich leider aber auch nichts dazu sagen, weil ich es - außer vom Namen her - nicht kenne und daher auch keine Erfahrung damit habe.
4:10 Achtung: Proof of concept code wird meiner Erfahrung nach oftmals nicht verworfen, sondern zum Produkt. Diese Entscheidung wird dann vom Management getroffen. Ist also eine Falle.
[gr] Das ist dann aber ein Fehler in der Unternehmenskultur / der Handhabung / vom Management - das macht den Rat ja nicht weniger wahr. Insofern ist nicht der Rat, so zu arbeiten, eine Falle, sondern die (leider allzu häufig) gelebte Kultur.
Ich find's schon aberwitzig, dass man im Studium diese testgetriebene, beweisartige (wissenschaftliche) Arbeitsweise nicht wirklich lernt und generell recht wenig programmiert. Heise hat erst gestern einen Artikel zur "Zukunft des Informatikstudiums" in Form eines Interviews mit dem Vorsitzenden für die Informatiklehre an deutschen Unis veröffentlicht. Also ist schon ziemlich gruselig, was der alles von sich gibt. Da schau ich doch tausendmal lieber Golo zu 😂
[gr] Ja … ich bin da auch etwas konsterniert: Auf der einen Seite habe ich schon durchaus ein paar Sachen im Studium gelernt, die ich nicht missen wollen würde, und mir ist auch klar, dass speziell das Studium an einer Uni eher theoretisch ist und mehr auf die Grundlagen abzielt, aber auf der anderen Seite finde ich es doch erschreckend, was alles nicht Bestandteil des Studiums war, beziehungsweise wie unausgewogen das teilweise war. Und, wie sehr von den Interessen einzelner Professor:innen das geprägt war … Wie auch immer: Ich freu' mich auf jeden Fall sehr über Dein Lob 😊
Code löschen ist doch sehr befreiend. Und schreibt man nicht alles drei mal? Einmal um das Problem zu verstehen, einmal um die Lösung zu verstehen und es beim dritten Mal richtig zu machen?
[gr] Genau das 😊 Wenn ich schon weiß, dass der erste Entwurf eh Mist sein wird, warum gebe ich mir dann Mühe, den in allen Ecken sauber zu machen? Dann doch lieber erst mal einen Quick'n'Dirty-Durchstich, lernen, Erfahrung sammeln, dann wegwerfen und auf Basis des Gelernten viel fundierter eine zweite Fassung bauen. Ironischerweise geht das unterm Strich auch meistens viel schneller, als wenn man die erste Fassung beibehält und dann versucht, daran herumzuschrauben …
Natürlich kommt das einem Anfänger, vielleicht auch noch im Web-Bereich, oft so vor als wäre das Problem der testgetriebene Ansatz. Mit der Erklärung schadet man aber eigentlich nur sich selbst. Ein paar kleine Tipps für Dich: Wenn eine Funktion einen Parameter mehr benötigt, fügt man diesen über ein strukturiertes Refactoring hinzu, Default ein neutrales Element. Löschen ist noch einfacher. Das ist überhaupt kein Problem mehr heutzutage, dauert keine zwei Sekunden und alle Tests sind auch gleich angepasst. Wenn die Tests vorher funktioniert haben sollten sie nun auch noch funktionieren, denn ein Refactoring ändert nur die Struktur, nicht das beobachtbare Verhalten. Wenn Du wie erwähnt hunderte Tests für eine Funktion hast ist die Funktion eindeutig zu groß. Wenn Du ein Problem nicht verstanden hast war die Vorbereitung nicht gut, vielleicht hast Du auch die Testfälle vorher nicht als „Shopping-List“ niedergeschrieben. Und nun stell Dir vor Du hättest Dir keine Gedanken über mögliche Testfälle gemacht und merkst erst kurz vor Schluss was Du alles vergessen hast!
Die Fehlerquote in meinem Team ist recht hoch, es wird auf mangelnde Tests, bzw. kein TDD verwiesen. Ich meine aber, dass der Großteil der Fehler passiert weil die Entwickler die Anforderung nicht verstanden haben. Die Qualität des Codes ist meist tadellos, aber es fällt den Leuten oft schwer sich in die betriebswirtschaftlichen Abläufe von Anfang bis Ende einzuarbeiten. TDD würde hier genauso sauberen, fehlerfreien Code liefern, der halt dann immer noch nicht tut was die Geschäftsleitung erwartet.
Deine Einwände gegen TDD sind genau die, die mich von TDD abhalten. Ich muss doch erstmal lernen, was ich da eigentlich mache. Aber die Idee im Hintergrund sorgt für einfache Funktionen auf der untersten Ebene, in der es letztlich keine Abhängigkeiten mehr gibt - und schon gar nicht zu geisterhaften injected Dependencies, für die man extra Testframeworks und aufwendige Mocks verwenden müsste! 😫🤦♀️
Hey Golo - heute sind wir einer Meinung. Leider bin ich nicht in Teams wo viel automatisch getestet wird. In meiner Firma wird gerade das Thema angegangen. TDD ist wirklich wichtig, aber es ist auch teuer. Man sollte TDD wirklich da einsetzen, wo wirklich wichtige Funktionen bzw. eine wichtige Businesslogik Bestandteile sind. Andere „nicht so wichtige“ Funktionen, kann um Kosten etwas zu relativieren normal testen und nicht TDD zu verwenden. LG Marcus
[gr] Ja, das stimmt. Es gibt Dinge, bei denen stehen Kosten und Nutzen in keinem Verhältnis. Entweder, weil die potenziell möglichen Fehler so trivial sind, dass sie ohnehin sofort auffallen würden. Oder weil es so schwierig ist, ein gutes automatisiertes Test-Setup hinzubekommen, dass man sich überlegen muss, ob sich das lohnt … Insofern: Ja, das ist richtig für mein Empfinden. Aber: Ich erlebe es leider zu häufig, dass von Vornherein genau damit argumentiert wird. Mir wurde mal von einem Unternehmen gesagt, sie würden nicht testen, weil ihre Entwickler so gut seien, "die machen keine Fehler". Ironischerweise kam diese Aussage in einem Gespräch auf, in dem es darum ging, wie sie ihre Qualität verbessern könnten … finde den Fehler 🤣
@@thenativeweb 🤣🤣🤣🤣 Solange das Unternehmen den Fehler selbst nie einsieht. Es gibt keine Fehlerfreie Software. Ja und es ist soooo unterschiedlich. Leider noch nicht überall angekommen, dass Testen mehr Vorarbeit erfordert, im Nachhinein aber eine imense Qualitätssteigerung ist, die kostengünstiger sein kann/wird.
Ich empfinde TDD als Mittel um gut strukturierten Code zu schreiben. Ganz einfach weil man so unbeschwert ein Refactoring betrieben kann. Als ich ohne Tests mit PHP arbeiten musste konnte ich zusehen wie mein Code verrottet ist... natürlich hat sich das Unternehmen stets selbst am meisten für Qualität gelobt... Aber hast schon recht, es löst das Problem nicht, es kann nur dabei helfen. Ich hab das Gefühl das auch da die Menschen so ein Allheilmittel suchen. Man muss ja nur... Spoiler: Dies wird es nie geben. :D nirgendwo! Hast du eigentlich ein fortgeschrittenen Video über automatische Tests? Also vielleicht auch weniger technisch, und mehr konzeptionell.
[gr] Wir haben schon mal ein paar Videos zum Thema "Testen" gemacht, die in die Richtung gehen dürften, was Du suchst: - Tests - wozu überhaupt? th-cam.com/video/Mjr-iQ-_umU/w-d-xo.html - Tests: Unit, Integration & Co: th-cam.com/video/A7ej4cgwgRk/w-d-xo.html - TDD: th-cam.com/video/71nLhdZuMk0/w-d-xo.html - Privaten Code testen, wie: th-cam.com/video/MZ76Haup3XY/w-d-xo.html - Wie testen nicht funktioniert: th-cam.com/video/t2GO0ijzGvY/w-d-xo.html Vielleicht ist da ja etwas für Dich dabei - falls nicht, sag gerne noch mal Bescheid 😊
Hallo, ich habe ebenfalls im privaten einige Systeme mit TDD entwickelt und als Programmieranfänger, der noch nich an großen Projekten mitgewirkt hat, dieses Werkzeug auf sich wirken lassen. Deine Ausführungen, zum Thema dass TDD manchmal überbewertet ist, sollten eigentlich selbstverständlich sein. Der Professor, ,der Anwendungsentwicklung in Verbindung mit TDD lehrt, geht genau diesem Grundsatz nach. Es macht wirklich überhaupt keinen Sinn, ins Bllaue hinein zu coden. Erst muss man sich ein klares Bild über das System machen, welches entwickelt wird. Je größer diese Systeme werden, desto mehr Zeit wird dabei natürlich vergehen. Aber die EInsicht von ihm, wenn man n-Tests geschrieben hat und all diese gehen positiv durch. Kann man zum derzeitigen Zeitpunkt sagen, man hat eine stabile und gute Software implementiert laut Tests, die man vorher definiert hat. Gerade das TDD verlangt eigentlich schon, dass man sich erstmal mit der Problemstelleung befassen muss, bevor man auch nur eine Zeile Code schreibt.
@@thenativeweb nein zum Glück nicht😅 In der Problemfindungsphase probiere ich oft herum ohne konkreten code zu schreiben, bis ich dann ungefähr verstanden habe wie es funktionieren müsste und lege dann mit TDD los. Aber bis heute bin ich davon ausgegangen, das meine TDD Erfahrung noch nicht ausgereift genug ist um von anfang an mit TDD zu beginnen. Stichwort "expolratives testing", wo man wohl tests für bestehende Interfaces schreibt, um herauszufinden wie sie funktionieren, wären da vielleicht ein Ansatz. Aber gut zu wissen das selbst die besten, wie du, hier ähnliche Probleme haben wie ich kleines Licht. 😇
Das ist der Grund, warum sich TDD ab und zu anfühlt wie "einen Marathon zu laufen - mit der Sichweite eines Mikroskopes -" ...man sieht den Wald vor lauter Bäumen nicht. Sehr ungünstig, wenn man sich dann zudem noch verläuft xD
2 ปีที่แล้ว +1
In dem Moment wo das letzte D als "Design" gelesen wird lassen die Diskussionen nicht lange warten ;) Ich finde das ist wie in der Kunst: Da gibt es viele Stile und wenn der Maler was kann kommt immer was "schönes" Raus (umkehrt nützt den Untalentierten wie ich es bin auch die beste Technik wenig). Aber klar gibt es einfacherere und schwierigere Techniken. Für mich ist TDD durchaus Anfängergeeignet - einfach nur deswegen weil es relativ leicht zu lernen und anzuwenden ist (bitte keine bösen Rufe - nicht vergessen: einfach zu Lernen und schwer zu Meistern - wenn man sowas gefunden hat ist es praktisch immer ein Hit). Aber es ist nicht der einzige Weg guten Code zu schreiben und es ist auch nicht jeder ein schlechter Entwickler der bei TDD nicht nur positive Erfahrungen gemacht hat ;) --- PS: wer ein bischen Spaß haben will (gibt dabei durchaus was zu Denken) und wem die Diskussionsserie die damals auf THHs "Test-induced design damage" damage (dhh.dk/2014/test-induced-design-damage.html) zu langatmig ist, dem kann ich das Video hier: vimeo.com/110554082 und für extra LOLs dann die Antwort von Uncle Bob blog.cleancoder.com/uncle-bob/2014/11/12/PutItInProduction.html empfehlen ;)
[gr] Oh ja … TDD als "Test-Driven Design" lesen, und dann kannst Du Dich am Besten einfach nur möglichst schnell rausziehen, Popcorn holen und zurücklehnen 🍿🤣
Ich habe ein paar Tage über dieses Video nachgedacht. 1. Der Inhallt trifft 100% meine Meinung 2. Der Titel ist trotzdem Click Bait, sorry. "Überbewertet" impliziert dass jemand eine Bewertung hat, die höher ist als... als was? Es gibt keine objektive und allgemein gültige Bewertung von TDD, also clicken die Hater und die Fanboys gleichermaßen auf den Link. Ein besserer Titel wäre "TDD hat Grenzen der Nützlichkeit" oder "TDD ist kein Allheilmittel" o.ä.
TDD ist tatsächlich keine gute Idee. ich habe es gezwungener Weise schon verwendet. Und ich habe auch kein Problem damit. Nur ist der Code der dabei rauskommt, meistens fürchterlich. Und es verbraucht eine Menge Zeit, die man besser in guten Code stecken sollte. Ich schreibe auch Tests. Sehr viele sogar. Aber die Testen keine Methoden, sondern Funktionalität. Das spart Zeit und ist letztendlich das einzige was zählt. Das was hinten rauskommt muss der Spezifikation entsprechen. Wie der Code da hinkommt ist irrelevant. Also teste ich das auch nicht.
Ich entwickle Software seit über 30 Jahren. Tests halte ich für wichtig, aber ja definitiv idR. ziehe ich die nach. Es gibt Ausnahmen - wie du schon sagst, wenn man was gut versteht. Da macht es dann Spaß Test für Test grün zu machen.
Ich habe letztens einen Parser geschrieben - die Sprache war 100% definiert. In dem Szenario hat TDD Sinn ergeben.
Das Wichtigste bei mir ist, dass ich für jeden Fehler der gefunden wird einen Unit Test nachzieht. Damit man dann später keine Regressions hat. Tests sind Werkzeuge und keine Religion.
[gr] Dein letzter Satz fasst das Ganze so schön zusammen: "Tests sind Werkzeuge und keine Religion." 😊
Vielen Dank für diese Ausführung.
Ich finde es immer wieder erstaunlich: Themen die mir durch den Kopf gehen bei denen ich mit nicht ganz sicher bin werden in vielen Eurer Videos durchgenommen und bestätigen meine Gedanken dazu.
Mit diesem Video ist es genauso, mir kam TDD auch oft hinderlich vor (aus den genannten Gründen) und nach längerem Gedanken machen und "verstehen" zeigte sich oft dass das vermeintliche Problem gar kein Problem ist.
Vielen Dank für Eure bisherigen Videos und für alles was kommen wird.
Auch beim Test-Code gilt DRY. Ich verwende deshalb (im Test-File) oft eine kleine Funktion zur Instanz-Erzeugung, ebenso kleine Wrapper-Funktionen für den Aufruf der zu testenden Operationen. Bei einer nachträglichen Änderung an der Signatur der zu testenden Methoden, brauche ich nur die Wrapper-Funktionen anzupassen.
Der Code zum Aufruf einer Wrapper-Funktion ist auch oft kürzer als der Code zum direkten Aufruf der zu testenden Operation.
Der Fachbegriff fuer die im Video beschriebene Vorgehensweise lautet uebrigens "Spike and Stabilize". Ein Spike ist ein oft von vornherein zeitbegrenzter Wegwerf-Prototyp um wie erwaehnt ein Gefuehl fuer das Problem zu bekommen und verschiedene Ideen auszuprobieren. Wenn der Spike erfolgreich war, muss man ihn stabilisieren und darf ihn nicht einfach als Endprodukt behandeln. Das kann entweder durch Neuschreiben oder durch Refactoring geschehen.
Um deine Eingangsfrage zu beantworten, Golo: Ich habe diese Video angeklickt, weil ich deinen Ausführungen unglaublich gerne lausche und immer etwas daraus mitnehmen kann. Dass mich das Thema zusätzlich noch interessiert, ist nur das Sahnehäubchen. 😁
Auf diesem Weg also mal ein riesiges Dankeschön für deinen Dienst an der Entwickler-Community. 👍
[gr] Vielen, vielen Dank - das ist echt lieb 😊
Wirklich tolles Video, dass alle möglichen Aspekte beinhaltet. Danke Golo.
[gr] Danke für das Lob 😊
Im "Originalbuch" des TDD wird das als "Explorative Coding" bezeichnet.
Der Autor verkauft dort das TDD als ein Werkzeug das sich an das notwendige Sicherheitsbedürfnis (notwendiges Confidence Level) anpasst. Er verweißt aber immer wieder darauf, dass man tendenziell lieber etwas zu vorsichtig ist als umgekehrt.
Das ist vor allem für Anfänger im TDD ein großes Problem. Man überschätzt sich ständig und nimmt in dem Zuge ggf. aus diesem Video die falsche Botschaft mit.
Dass man die Public API des zu Testenden Codes ständig ändert ist oft auch ein Hinweiß, dass man das Problem nicht weit genug zerlegt. Die Testfälle sind also zu komplex, das System ist nicht modular genug und das merkt man daran, dass man immer wieder viele Testfälle gleichzeitig anpassen muss. Es spricht auch nichts dagegen, code den man eigentlich nur zum testen braucht selbst unter Testkontrolle zu stellen, wenn dieser eine gewisse komplexität erreicht.
Als Programmierer, das sich sein leben lang sein Hirn an fast unlösbaren Problemen zermartert hat und die Bestie mit bösen hacks gezähmt hat, ist die TDD Welt nach einer kurzen Zeit bereits so paradisisch, dass man oft den Weg nicht bis zu ende geht, weil man sich einfach nicht vorstellen kann, dass es noch einfacher und noch besser werden kann. Man fühlt sich bisweilen von der trivialität unterfordert und denkt, ach das geht auch so.
TDD braucht einfach Zeit zum erlernen sodass man die ganzen schlechten Angewohnheiten ablegen kann, die man schon garnicht mehr in Frage stellt. Es ist einfach eine ganz andere Art zu programmieren.
Es gibt noch eine dritte Möglichkeit warum ich mir das anhöre: weil es von dir ist und ich finde du machst das ausgezeichnet! Du lieferst sehr interessant Inhalte sehr pointiert, kurzweilig und informativ. Danke für deine Mühe - freue mich schon auf Weiteres! 😊
Schönes Video, ich würde ein wenig ergänzen:
- Unit Tests geben einen Entwickler auch ein Gefühl oder Hinweis, wie etwas zu implementieren ist. Oft bemerke ich, dass noch eine Klasse oder ähnliches fehlt. Unit Test fördert klar das Schreiben kleiner Klassen (SRP).
- Selten habe ich den vollständigen Blick, was ich alles benötige für eine Anforderung. Eine gute und vollständige Anforderung benötigt einen guten Vermittler von Anwender zu Entwickler. Der Vermittler muss dann auch Test + Daten stellen. Fehlt der wird es schwieriger bei der Umsetzung. Dann sind Unit Tests noch wichtiger, weil man ggfs oft den Code umstellen wird.
- Was auch passieren kann, dass man zuerst die externen Komponenten ausprobieren will. Da bietet sich ein POC eh an.
- Gerade Randbedingungen bei Tests fallen mir zum Teil 1 oder 2 Tage nach der Implementierung ein. Aber zum Teil war ich auch mathematischer bzw algorithmischer Unterwegs (NP Probleme, geometrische Algorithmen usw).
- Unit Tests sind zum zeigen, wie Code angesprochen werden kann. Gar nicht schlecht für jemanden, der dagegen Programmieren soll. Zumindest hat man ein kleines Beispiel, welches man auch zusammen debuggen kann.
- Jeder Fehler, der durch Tickets reinkommt, kann man meist recht einfach mit einem Unit Test abbilden. Was ein riesiger Vorteil ist, wenn man gut loggt, zum Beispiel die Übergabeparameter als JSON loggt oder ähnliches.
- Bei Erweiterungen am Bestandscode kann ich zumindest sicher sein, dass Bestandstest immer noch laufen und somit altes Verhalten gewährleistet wird. Ohne Tests wird irgendwann an Bestandscode wenig oder gar nicht mehr angepasst und wenn dann nur, wenn es sein muss.
Aus Erfahrung würde ich meinen, dass man mit Test locker 80-90% der üblichen Fehler vermeidet, die einem sonst auf die Füße fallen würden. Alleine das ist der Grund Tests zu schreiben. Weniger stress Fehler schnell zu beseitigen, weniger unerwartete Tickets, mehr Zeit für eigene Entwicklungen, weniger Zeit für integrative Tests vergeuden. Das sind nur wenige Punkte, die es eigentlich unabdingbar machen.
[gr] Danke für Deinen Kommentar 😊
Richtig, erst muss man das Problem in die algorithmische Ebene bringen, das ist eine Denkleistung welche einem von Tests prinzipiell nicht abgenommen werden kann. Sobald man aber einen Lösungsansatz zur algorithmischen Dekomposition der Aufgabe hat, kann man diesen durchaus mit TDD entwerfen, um eine Struktur reinzubekommen, und früh an die Designfehler aufmerksam zu werden.
Da ich mal das programmieren mit Eiffel unglaublich heftig gemacht und geliebt habe. Gehe ich einen anderen Weg der leider nur in Eiffel perfekt war. Man nutzt die Tests um die Szenarien die später benutzt werden ablaufen zu lassen, man schreibt aber keine REQUIRE tests gleich am Anfang. Damit kann man erstmal interaktiv loslegen zu entwickeln und auszuprobieren. Die korrektheit wird dann nicht in den Tests sondern durch Design By Contract erledigt, das heisst man schreibt sehr sehr viele assert statements an allen Punkten. Und fuer einige Dinge dann verpackt in Algorithmen, z.B. eine besondere "equals" Funktion die man dann einsetzen kann um nach jedem ein Undo/Redo zu testen. D.h. vieles wandert vom Test in den algorithmischen funktionalen Teil und der wird wie der Code inkrementell entwickelt und nicht am Anfang. Erst am Ende von Version 1 oder sogar Version 2 fuegt man dann Endtests ein fuer ein spaeteres groesseres Refaktoring und bevor man sein Kleinhirn von den Details wieder leert um mit etwas anderes zu machen.
Hinweis: Ich habe mit 14 angefangen zu coden und das ist jetzt 40 Jahre her. Professioneller Software Entwickler im nicht Web Bereich.
[gr] Ich habe leider von Eiffel überhaupt keine Ahnung, aber das, was Du beschreibst, klingt schon sehr spannend … danke für's Teilen 😊
Ja, Eiffel ist an der Stelle superdurchdacht, auch wenn ich DbC nur in anderen Sprachen angewendet habe, Ich habe mit Invarianten schon sehr knifflige Sachen entdeckt auf die ich sonst nicht gekommen wäre (wenn z.B. Kollegen unbedacht Datenbank-Constraints ausgeknipst oder Datenbankeinstellungen wie Encoding oder Genauigkeiten verändert haben…).
Unterschreibe ich komplett!!
Dank für Deinen Beitrag!
[gr] Vielen Dank 😊
...Studium... ...undenkbar... viel zu prakmatisch... *instant like* :)
[gr] Danke schön 😊
pragmatisch oder prank-matic ? 😀
Ich habe das Video jetzt 42 Sekunden angeschaut und mich hat Grund Nr. 2 getriggert :D
Edit: Wirklich gut erklärt. Ich habe mir Disziplin antrainiert, nachdem ich paar mal an wirklich schlimmen Code mitarbeiten musste. Beim Programmieren wird oft und viel Code gelesen, statt geschrieben und wenn man den Code nicht mehr lesen kann, wird die Arbeit zur Qual. Es ist einfach ein Unterschied ob du nach einer halben Stunde, dich in einer fremden Software schon orientrieren kannst, oder auch nach einem Jahr immer noch nicht in der Software durchsiehst. Hatte ich nämlich beides und gehe notfalls auch auf konfrontation. Das Motzen hat mir auch Jobs gekostet, aber danach musste ich mich damit wenigsten nicht mehr rum ärgern.
[gr] Haha 😊
Und zu Deinem zweiten Absatz: Danke schön! Und ja, klar will man nicht immer die Übelkrähe sein, aber letztlich hilft es ja nichts (vor allem einem selbst am allerwenigsten), wenn man unzufrieden ist.
Du hast mich mit dem WebAssembly Video gepackt und nun verfolge ich auch deine anderen Videos. Wirklich gute Ausführungen, danke.
Ich bin seit 6 Jahren Vollzeit-Entwickler und kann dem nur zustimmen.
Die meisten Probleme, die ich sehe, sind neue Probleme. Vorab schon zu wissen, wie meine Lösung aussieht, erlahmt mich unglaublich, und es macht auch keinen Spaß. Stattdessen macht es mir großen Spaß meinen zuerst geschrieben Code mit Tests abzudecken, und dann diesen zu refactoren, weil man dann genau sieht, wo die Schwachstellen sind.
Ein Wegschmeißen habe ich noch nicht probiert, ist aber ein spannender Ansatz. Und ja, ich würde sagen, rund 80% des Aufwands, ist es das Problem richtig zu verstehen.
[gr] Danke schön 😊
Vor allem: Wenn es bereits ein bekanntes Problem mit einer bekannten Lösung ist - wieso entwickle ich das dann neu? Das könnte man dann ja eventuell auch einfach kopieren 😉
Das mit dem Wegwerfen ist tatsächlich ein spannender Ansatz. Vielleicht machen wir dazu noch mal ein Video, in dem wir zeigen, wie wir an eine Komponente herangehen.
Ich persönlich habe schnell genau diese Erfahrung gemacht.
Zum Glück habe ich bei meinem letzten Arbeitgeber die volle Ladung input zu TDD bekommen. Was nicht bedeutet hat dass ich am Ende TDD entwickelt habe - aber dennoch meine letzten projekte mit >90% test-abdeckung abgegeben habe.
Ich konnte einfach nicht auf die art und weise denken "vom test zum code" und zugleich im blick behalten wie ich das Problem (eigentlich in dem Fall Features) lösen kann.
Denn der Weg zum fertig entwickelten Feature ist einfach häufig kein gerader weg.
Man kann sich häufig weder von Top-to-bottom noch umgekehrt geradewegs durcharbeiten. So geht es mir zumindest.
Ich behalte im Blick, dass die Klassen klein genug sind und die Architektur stimmig und offen ist. Bis man da angekommen ist dauert es etwas und in der Zeit kann ich und will ich für etwas das noch nicht stehen bleiben kann tests entwickeln.
Ein Test ist die technische Dokumentation einer Anforderung.
[gr] Das stimmt, und das ist eine schöne, kompakte Definition 😊
@@thenativeweb jetzt habe ich mal die vielen guten Diskussionen (oft mehr als nur Kommentare) gelesen.
Dieser frühe Kommentar gefällt mir auch gut, weil er eine wichtige Frage aufwirft, die hier wenig angesprochen wurde:
Wer sollte einen Test schreiben?
Wenn es die "technische Dokumentation einer Anforderung" ist, könnte/sollte doch der Product Owner diese Test schreiben - oder jemand, der die Sicht des Produkt-Owners spezifizieren/konkretisieren will, was ja auch ein Entwickler sein kann, der anschließend die Implementierung angeht und durch das Test schreiben sicher stellen will, den Product Owner richtig verstanden zu haben. Insofern sollten "Tests" doch die Dialogsprache zwischen Product Owner und Developer sein. Ein Product Owner muss ja die Implementierung nicht verstehen (black box) - aber das Verhalten ist die domain des Product Owners.
[gr] Das ist richtig, das setzt aber letztlich voraus, dass auch der Product Owner zumindest soweit programmieren kann, dass sie beziehungsweise er die Tests formulieren kann.
Oder man verwendet ein Konstrukt wie Gerkin und BDD, wobei ich noch nie in der Praxis gesehen habe, dass es wirklich gut funktioniert hat. In der Regel funktioniert das nicht ohne Entwickler, aber vielleicht habe ich dafür auch einfach nur die falschen Beispiele gesehen.
@@martinhovekamp8315 Die wörtliche Dokumentation der Anforderungen wird doch auch von den Entwicklern des System geschrieben, und dann dem Kunden gezeigt und abgeglichen ob man nun verstanden hat was der will. Bei den Tests könnte es ähnlich laufen. Und wenn man die Sprache des Kunden ("ubiquitous language") verwendet, müsste er sich in einer guten API quasi wie von allein zurecht finden - zumindest auf der obersten Abstraktionsebene.
Vielen Dank und meinen höchsten Respekt für deine Sichtweise und deine Art es zu vermitteln. Ich selbst höre auch immer wieder hitzköpfige Vorgesetzte die gern alles und jeden in TDD arbeiten lassen würden und viele Entwickler die denken Testen sei etwas für Entwickler die nicht wüssten was sie tun. Meist macht deren Arbeit aber eher den Eindruck als wüssten sie das selbst nicht.
Wirklich oberster Punkt ist dass man seinen Code testbar schreibt. Das KANN man meiner Meinung nach durch TDD lernen, wichtiger ist aber sich und seine Arbeit immer wieder zu hinterfragen, bei den Tests nicht darauf zu achten, dass die Abdeckung erreicht ist und jede Zeile in der IDE irgendwie grün wird sondern das man die Tests als eine Art Dokumentation des Codes sieht und auch so versteht. So lernt man bessere Tests zu schreiben und merkt auch mehr und mehr, meiner Meinung nach, wo es beim Code noch klemmt bzw. was man eleganter Lösen sollte.
TDD ist wie OOP und andere Paradigmen. Es gibt leider viele Fanatiker die nur hören "ich finde es scheiße, wenn ich es nicht gut finde", aber sie denken nicht darüber nach, WARUM es so ist, wollen es meist nicht einmal hören.
Du hast erst ein Video gemacht (bzw. habe ich es jetzt erst gesehen) zum Thema Design Patterns. Dort hast du es eben so gut erklärt, es gibt kein Gut und Schlecht hinter Techniken. Es ist immer der Anspruch des Entwicklers der es optimal einsetzt oder es übertreibt. Keine Technik ist per se schlimm. Es ist immer das Maß und vor allem das Mögliche im Vergleich zum Notwendigen.
Danke dass du deine Anspruch mit der Welt teilst. Ich wünschte mir viel mehr Menschen wie dich in der Welt der Entwickler. Dann wären nicht so viele Projekte so grottig und zum scheitern verurteilt, wenn sie eine Renaissance erfahren sollen. Es wäre nur wünschenswert, Entwickler mit weitaus weniger als deinem Anspruch würden deine Videos sehen und vor allem Verstehen und beherzigen!
Es ist immer schön zu wissen, dass es mehr Menschen mit Anspruch gibt, als "nur" mein Team ;)
[gr] Danke schön 😊
@@thenativeweb Nicht dafür. Ich danke dir für deine Anspruch und deine Qualität. Sehr selten und so extrem wichtig.
Ich freue mich über jeden, der so über diese wunderbare Arbeit denkt und damit umgeht.
Eine Best Practice die hilft Tests bei Refactoring nicht exzessiv umschreiben zu muessen ist, nur oeffentliches (public) Verhalten zu testen. D.h. nicht testen WIE etwas intern implementiert ist, sondern nur das der Code das richtige nach aussen hin tut. Refactoring hat ja das Ziel, die interne Code-Struktur oder Performance zu verbessern ohne das externe Verhalten des Codes (was durch Tests validiert wird) zu veraendern.
[gr] Das ist richtig: Tests sollten auch für mein Verständnis Blackbox-Tests sein, die nicht von der internen Implementierung abhängen dürfen. Tests sollen Verhalten und nicht Implementierung testen.
Leider schützt das trotzdem nur bedingt vor dem Problem, größer umschreiben zu müssen, dann nämlich, wenn die Public-API zu Beginn unpassend entworfen wurde.
Einfaches Beispiel: Nach ein paar Stunden stellt man fest, dass man zum Beispiel lieber Tag, Monat und Jahr einzeln statt als Date-Objekt übergeben will, oder man stellt fest, dass ein bestimmter Parameter unnötig ist, oder oder oder …
Das ändert aber nichts an der Relevanz und Korrektheit Deiner Aussage: Tests sollten stets nur von Außen testen, ohne Kenntnis des Inneren.
Großartiges Video! Ich würde sogar noch weiter gehen und sagen, dass 100% Abdeckung unnötig sind, wenn man erfahren genug ist. Ich beziehe in die Bewertung, ob ein Test notwendig ist immer folgend Kriterien ein
- Aufwand des Testens (je niedriger desto test)
- Wahrscheinlichkeit des Fails (je höher desto test)
- Stärke der Auswirkung eines Fails (je höher desto test)
- Änderungshäufigkeit (je höher desto test)
- Wichtigkeit des Codes (je höher desto test)
- Komplexität eines äquivalenten manuellen tests (je höher desto test)
Nach diesen Kriterien teste ich z. B. selten reine Ausgabeerzeugung (Rendering), aber z. B. immer (Restful)-APIs und utility-Funktionen
[gr] Das finde ich eine durchaus hilfreiche und durchdachte Vorgehensweise 😊
100% bekommt man in der Regel nur bei Stateless Systemen überhaupt hin. Dennoch ist es ein gutes Gefühl, wenn alle Branches in einer Funktion getestet sind. Wie oft habe ich schon Bugs in Exception Handlern gefunden…
Mach ich intuitiv schon immer so :) Erst basteln und dann nochmal schoen machen und tests schreiben.
TDD ist das Gegenteil. Erst Tests, dann Code.
@@stell4you Mir ist klar was TDD ist. Hast du das Video komplett angesehen? Mein Kommentar bezieht sich auf eine Aussage spaeter im Video und damit auch auf die Kernaussage des ganzen Videos.
hi, frage: ist nicht genau der prozess des herausfindens, was das problem ist, der eigentliche fokus des tdds? also das ständige hin und her zwischen test und code, was du als mühsam etc beschreibst. als "nebeneffekt" hat man dann halt hinterher auch eine gute testabdeckung und gut strukturierten code, gerade weil man sich halt im ständigen dialog zwischen test und eigentlichem code der lösung des problems auf methodische weise angenähert hat. also würde man hier doch tdd tatsächlich einen gewissen selbstzweck unterstellen können, im sinne einer methodik zumindest, oder? wenn ich mir zb das buch test driven by example oder das berühmte bowling-kata ansehe, das ja auch in "agile software development, ppp" von martin dargestellt wird, denke ich, dass hier die methodik sehr gut verdeutlicht wird. im "gegensatz" dazu wäre halt erst das problem lösen und danach tests schreiben eine option, aber dann ist es halt kein tdd. aber undogmatisch damit umgehen ist immer gut, finde ich. danke für die denkanstöße!
[gr] Das, was mich daran stört, ist, dass es sehr ineffizient ist. Gerade die Bowling-Kata (siehe codingdojo.org/kata/Bowling/) ist ein schönes Beispiel: Ich persönlich habe sie noch nie gemacht. Wenn ich sie machen würde, würde ich folgendermaßen vorgehen:
- Problem auf Papier skizzieren und über Lösungsansätze nachdenken (wie gehe ich überhaupt vor) … dazu gehört auch, sich Datenstrukturen zu überlegen, und ähnliches.
- Damit komme ich zu einer Annahme, wie ich es lösen könnte. Ich weiß aber nicht, ob das tatsächlich richtig ist. Bei trivialen Problemen mag das offensichtlich sein, bei komplexeren nicht.
- Deshalb möchte ich als nächstes meine Annahme validieren. Das heißt, überprüfen, ob der von mir erdachte Ansatz überhaupt funktionieren kann, oder ob ich etwas essenzielles übersehen habe. Dazu schreibe ich das Ganze mal Quick'n'Dirty runter.
- Erkenntnis in 99% der Fälle: Ich habe etwas übersehen und muss an meinem Konzept nacharbeiten. Das kann durchaus zwei, drei Iterationen brauchen.
- Wenn ich das habe, dann weiß ich langsam auch, wie meine Signaturen aussehen, welche Funktionen ich überhaupt brauche, und es entwickelt sich ein Gefühl für die Frage, wie ich das ganze strukturieren kann.
- Und dann werfe ich meinen experimentellen Code weg und schreibe es mit Tests neu, und das kann dann gerne auch nach TDD sein.
Nur dieser eine letzte Schritt ist tatsächlich "Code schreiben" im Sinne von "die finale Lösung entwickeln". Alles davor ist Entwerfen, Validieren, Verstehen, Lernen. Dabei hilft mir persönlich TDD nicht, eher im Gegenteil. Vielleicht schreibe ich mir auch dafür schon mal ein paar Tests, aber nicht nach TDD. Weil das Ziel eben hier noch nicht ist, eine gute Struktur zu haben und die Funktionalität mit all ihren Spezialfällen zu überprüfen, sondern erst einmal nur, ein Bild von einer sinnvollen Vorgehensweise zu bekommen.
Aber, wie gesagt: Das ist *meine* Vorgehensweise. Wer das von Vornherein nach TDD machen will, kann das ja gerne tun - nur *mir* wäre das zu aufwändig, weil ich TDD nicht als hilfreich empfinde, um die Lösung zu designen.
Ich finde den Abschnitt "Wann TDD keine gute Idee ist" nicht überzeugend. Aus mehreren Gründen:
1. Die Signatur einer Funktion braucht in den Tests nicht nachgezogen zu werden, denn die Tests testen ja einen Fall, in dem der Wert für den zusätzlichen Parameter immer gleich ist. Folglich bekommt der neue Parameter einfach einen Default-Wert, sodass er beim Aufruf der Funktion optional ist.
2. Wenn du das Problem als ganzes noch nicht verstanden hast, kannst du immer bei dem Teil des Problems anfangen, den du verstanden hast. Ein typisches Muster bei der Arbeit mit TDD ist, dass du das "eigentliche" erst ziemlich am Ende machst, d.h. bei einem Algorithmus fängst du mit der Abbruchbedingung an, dann nimmst du einen Fall der im Anschluss direkt zur Abbruchbedingung führt, etc.
Ein Problem mit TDD bekommst du dann, wenn du in fragile Tests schreibst. Aber das lässt sich vermeiden, indem man von vornherein immer nur das (zukünftige) Facade-Objekt für einen Kontext testet und schrittweise eine Klassenstruktur hinter dieser Facade errichtet.
[gr] Ad 1: Dann habe ich unter Umständen einen Parameter, der testbedingt (!) optional ist, obwohl das aus fachlicher Sicht nicht sinnvoll ist. Abgesehen davon funktioniert der Ansatz mit optionalen Parametern spätestens dann nicht mehr, wenn man einen Parameter zum Beispiel semantisch ändert - beispielsweise Tag, Monat und Jahr als drei Argumente übergeben statt ein Date-Objekt. Das greift IMHO zu kurz.
Ad 2: Klar kann ich dann mit dem kleinsten Teil anfangen, den ich schon verstanden habe - nur wenn sich dann im Lauf der Zeit herausstellt, dass ich das Pferd aus Unwissen von der falschen Seite aufgezäumt habe, habe ich trotzdem Tests geschrieben und unter Umständen eine Menge Zeit aufgewendet, für letztlich nichts.
Daher bleibe ich dabei, dass ich es für sinnvoll erachte, zunächst mit einem Durchstich / Proof-of-Concept / Spike zu gucken, wie man das Problem lösen kann, bevor man es richtig löst.
Frei nach dem Pretotyping-Motto: "Ensure that you do the right it before you do it right."
Ein schönes Beispiel, wie TDD bei schlecht verstandenen Problemen bzw. bei explorativem Programmieren schiefgehen kann, findet man, wenn man nach "sudoku tdd ravimohan" googelt.
[gr] Danke für den Link (beziehungsweise die Anregung zum Googlen) 😊
8:55 Genau, nur bei den einfachsten Aufgaben ist es der Fall, daß man weiß wie die Lösung zu programmieren ist. Ein weiterer Einwand gegen TDD ist die Tatsache, daß es versucht (auch wenn ungewollt), den Entwickler zum Scheitern zu gewöhnen, was psychologisch nicht gut ist. Man fängt immer mit einem Test an, der fehlschlägt. Ein Vorgang wo man viel häufiger Scheitern erlebt als Erfolg ist entwicklerfeindlich.
Ist es nicht viel cooler wenn danach die Pipeline grün ist? :D
@@martinmusli3044 Und: mit KI wird es sowieso alles von Anfang an grün ☺
Bei uns im Studium (ähnliche Zeit) wurde es zumindest mal erwähnt. Blieb aber abstrakt. Ich arbeite nicht mehr als Entwickler, habe mich aber irgendwann mal mit automatisierten Tests befasst und war beeindruckt.
Was mich mal interessieren würde aus der Praxis: wie gut schafft man es, mit TDD alle Eventualitäten, die in Praxis vorkommen können, zu bedenken? Schon beim Beispiel IBAN-Validierung gibt es ja alle möglichen Fehlerquellen: zur lang, zu kurz, Leerstring, richtige Länge aber ungültig, unzulässige Zeichen etc. Schreibt man dann für alle einen Test?
[gr] Ja. Das ist natürlich viel Aufwand, aber … 😉
Angenommen, Du schreibst keinen automatisierten Test dafür, dann können diese Fälle ja trotzdem in der Praxis auftreten. Die Frage ist nur: Was passiert dann? Bestenfalls hat jemand vorher darüber nachgedacht, und fängt es ab. Aber wie? Ist das auf Dauer konsistent? Oder ändert jemand das irgendwann, oder baut einen Spezialfall ein und ändert damit die Semantik, was aber sonst niemand mitbekommt, weil es eben keinen Test gibt, der das abfängt und überprüft?
Insofern ist der automatisierte Test kurzfristig mehr Aufwand, sorgt aber zum einen vor allem dafür, dass man sich mal fragt, welche Fehlerfälle es überhaupt alle geben kann, was zu expliziten Entscheidungen und nicht zu impliziten Annehmen führt, was den Code letztlich robuster macht, und zum anderen sorgt es dafür, dass es eine dokumentierte (denn Tests sind letztlich nichts anderes als automatisiert überprüfbare Design-Entscheidungen!) Entscheidung gibt.
In der Regel schreibst du einen Data-Driven Test, der als parameter dann eine IBAN (string) und eine erwartete Gültigkeit (bool) entgegennimmt. Je nach Sprache und Testframework kannst du dann recht einfach diverse IBANs an den Test übergeben. So musst du 1x die Testlogik (~10 Zeilen) und 20x mögliche IBANS mit Gültigkeit (1 Zeile jeweils) übergeben. Musst also um 20 IBANs zu prüfen nicht 10x20=200, sondern nur 10+20=30 Zeilen Code schreiben.
Ich habe sehr lange als C# Entwickler gearbeitet und dort immer automatische Unit-Tests geschrieben. Seit 2 Jahren arbeite ich jetzt primär als JS Entwickler und dort sind Unit-Tests eher die Ausnahme. Wir verwenden so gut wie keine Frameworks und fangen auch gerade erst an auf „Web Components“ umzustellen. Das größte Problem sehe ich im bootstrapping unsere Anwendung. Wie kann man so etwas effizient und einfach Testen?
[gr] Um ehrlich zu sein tue ich mir etwas schwer, Dir diese Frage zu beantworten. Was genau würdest Du denn testen wollen? Ich glaube, wenn Du das etwas näher einkreisen kannst, fällt es mir leichter, Dir eine sinnvolle und hilfreiche Antwort zu geben. Eventuell wäre das aber auch etwas für unseren Community-Discord - für den Link siehe Videobeschreibung.
Fände auch ein Video zu: "Warum OOP überbewertet ist" interessant
[gr] Danke für die Anregung 😊
Zu der Frage der Disziplin. Ich kann dem nur voll zustimmen, dass dies die Ursache vieler Probleme ist egal ob man TDD einsetzt oder erstmal nur Proof of Concept Code schreibt, aber oft liegt es auch einfach an der Firmenkultur wie mit Technical Debt umgegangen wird. Als Softwareentwickler steht man in vielen Firmen heute sehr unter Druck in kürzester Zeit Lösungen zu entwickeln und leider ist für langfristige gute Code Qualität oft keine Zeit. Ich glaube das liegt daran, dass in den Schlüsselpositionen der deutschen Industrie sich noch viele Personen tummeln, die von ihrem Mindset noch in der Ära der Wasserfallmodellentwicklung aufgewachsen sind wo testen halt erst ganz am Ende eingeplant ist und sowieso mehr als Zeitpuffer für alle möglichen Verzögerungen dienen musste.
Auch wenn die aller meisten heute in kürzeren Entwicklungszyklen arbeiten und das auch bei den meisten Leuten in den Schlüsselpositionen angekommen ist, so wird dennoch Pair Programming und TDD als Zeitverschwendung angesehen.
@@Apenschi ich glaube ich kann mit Sarkasmus nicht umgehen, der Kommentar hat mich echt getriggert und ohne die ";-)" hätte ich komplett am Rad gedreht ^^
PP ist immer gut selbst wenn alle Entwickler sehr erfahren sind, allein für den knowledge transfer und auch um überhaupt wirklich "meaningful code reviews" machen zu können.
@@Apenschi mit "immer gut" meinte ich hier eher sowas wie oft von Vorteil ^^
Aber diese ganze Kosten Nutzen Analyse kann man gar nicht IMMER so gut machen ;-)
weil man nicht weiß welcher Fundamental wichtige Knowledge Transfer durch Zufall bei einem PP Zustande kommen kann, der vielleicht dazu führt das man auf ganz neue Ideen kommt, die zu völlig neuen Geschäftszweigen führen und vielleicht zu einer Millionen schweren neuen Markterschließung führen.
Das Argument mag zwar was weit hergeholt sein, ist aber so schon öfters so in Unternehmen passiert und in abgeschwächter form passiert sowas gar nicht mal so selten.
Letztens noch mit einem Kollegen durch Zufall bei einer PP Session einen furchtbaren Bug gefunden, der dazu geführt hat, das bei einer seltenen aber nicht unmöglichen User Konfiguration ein Laser beim Beenden eines Prozesses nicht abgeschaltet wird. Für die Kosten Nutzen Rechnung hätten hier womöglich Menschenleben mit einbezogen werden müssen.
@@Apenschi ich kann verstehen wo deine eher realistische Perspektive auf PP herkommt, aber aus eigener Erfahrung muss ich sagen, dass es mittelfristig nur Vorteile bei mir bislang hatte und der Grund es sei zu teuer ein schlechter Grund ist. Man muss ja nicht gleich zwei Entwickler für 2 Wochen in einen Raum sperren um zusammen an einer Aufgabe zu arbeiten aber Mal eine 2h Session hat keine wirklichen Nachteile. Man schaut sich ja auch einen guten Arbeitstil und den ein oder anderen Trick beim anderen ab und dafür reichen auch kurze Sessions alle paar Wochen.
@@Apenschi Kann sehr gut sein, dass mir für eine allgemeingültigere Einschätzung einfach die Berufserfahrung fehlt und so wie du die Situation beschreibst ist das vermutlich auch schwierig mit PP.
Ich würde aber dennoch mal versuchen eine naive allgemeingültige Aussage zu machen: Da wo Teams mehr code lesen als sie schreiben am Tag ist der Nutzen von PP größer als die Kosten.
So wie ich PP verstanden habe, steht beim PP nicht im Vordergrund wie viel Prozent der Zeit bei einer Aufgabe zwei Leute wirklich zusammen vor einem Rechner Sitzen, sondern das sie eben nicht nur eine Code review zusammen machen, sondern wirklich zusammen herausfinden wie ein Problem gelöst werden kann und wirklich produktiver Code zusammen geschrieben wird und keine konventionelle Arbeitsteilung stattfindet. Eine klassische Review ist auch somit nicht mehr nötig, es sei denn noch eine dritte Person soll den Code überprüfen. Je nach Teamgröße und Art des Agilen (oder auch non-Agilen) Workflows sind ja zwei Reviewer Standard.
Ich bin zwar nicht sonderlich zufrieden mit der Branche (Maschinenbau) in der ich derzeit als Softwareentwickler arbeite was so die Workflows angeht, aber ich möchte nicht in einer Branche arbeiten, wo mehr Code geschrieben als gelesen wird. Das Stelle ich mir dann schon ziemlich Oberflächlich vor, wenn sich keiner wirklich mit dem auseinandersetzt was andere tun. Oder alle sind so selbständig und schreiben so Agnostische Apis um ihre Komponenten, dass einfach alles funktioniert mit reiner blinder Verständigung. Das wiederum fänd ich enorm beeindruckend und die Tools um diese Entkopplung zu gestalten gibt es sicherlich (gRPC + protobuf oder Open Api oder sowas).
Aber die größte Fehleinschätzung gegenüber PP ist sicherlich der Kosten Grund und dies liegt einfach daran wie die Arbeiteffizienz eines Softwareentwicklers bisher in der Industrie vor allem aus Human Ressource sicht gesehen wird. Das wäre nochmal eine ganz andere Diskussion.
@@Apenschi Kann ich nur zurück geben, ist ja selten genug geworden, dass man sich in den Kommentaren vernünftig unterhalten kann, wobei auf dem Channel hier echt nette Leute unterwegs sind.
Geschnitten Brot ist die beste Erfindung der Menschheit.
Vielen Dank!
[gr] Danke schön 😊
Meine Herangehensweise ist, Forschungscode in einem Verzeichnis "playground" zu entwickeln. Verworfen werden gute Codeteile nicht. Sie werden einfach in die getestete Umgebung herausgezogen. Für ein Deployment dürfen keine Abhängigkeiten zum Playground mehr bestehen.
Mit TDD habe ich meine Schwierigkeiten, diese Methodik anzuwenden, wenn ich eine Software auf Basis einer Event-Driven Architecture entwickle. Da werden die Nachrichten ja mehr oder weniger mit fire-and-forget gefeuert und an sich kann ich da ja nat. kleine Teile testen, aber ein Systemtest als TDD wird da schon schwierig, finde ich.
Grundsätzlich finde ich TDD aber gut und für die kleinen Teile verwende ich das (z.B. Aufbau der Domain), aber bei ganzen Architekturen habe ich es ggf. noch nicht verstanden.
Danke, kann vollständig unterschreiben. Und eventuell ergänzen. Es muss klar sein, in welchen Rahmen diese Entwicklung stattfindet. Wenn man eine bestimmte, aber unbekannte Domäne angeht, dann sammelt man erstmal Erfahrungen. Manchmal lange, manchmal nicht. Irgendwann wird man darin ein "Meister" bzw. eine/er mit sehr fundierten Erfahrungen. Doch. Wenn man soweit ist, wo ist die Garantie, dass man es weiter gestaltet oder es wird an die anderen weiter gereicht. Sind die Tests so was wie Wissenstransfer?
Eine andere Sache. Wenn man Meister im den anderen Berufen beobachtet, dann stellt man fest, dass dort eine Zeit gearbeitet wird, danach nur 'aus dem Bauch heraus Entscheidungen ' getroffen werden. Egal ob beim Automechaniker, Chirurg oder dem Tattoo-Macher usw. Irgendwann kommt der Punkt, wo es einfach im Blut ist und die nächste Handlung oder Umsetzungsidee immer die richtige ist. Dann braucht man keine Tests mehr. Doch nur für sich. Daher, wenn ich meine eigene Projekte egal, ob in der Software-Entwicklung oder beim Hausbau, beim Schweißen oder beim Kochen durchführe - also da, wo ich schon Jahrzehnte an Erfahrungen habe - brauche ich keine Tests mehr.
[gr] Da bin ich fast bei Dir - der Unterschied zwischen den von Dir genannten Branchen und der Softwareentwicklung ist, dass zB das Schweißen oder das Operieren ein Produktionsprozess ist, die Softwareentwicklung aber eben ein Entwicklungsprozess. Das heißt, es geht bei der Softwareentwicklung viel häufiger um das explorative Erkunden von Neuem (wenn dem nicht so wäre, könnte man eine vorhandene Lösung ja einfach kopieren). Ein Hausbau läuft aber im Wesentlichen stets nach Schema F ab.
Und das ist der Punkt, warum ich Tests trotz allem langfristig wichtig finde: Bei einem Hausbau änderst Du nicht mehr den Keller, weil Du beim Bau des zweiten Stockwerks feststellst, dass da was nicht passt. Das weißt Du vorher, wie Du sagst "aus Erfahrung", weil man es schon hundert Mal gemacht hat. Bei Software ist das anders. Da muss ich gegebenenfalls auch noch mal an das Fundament und das anpassen.
Und da möchte ich dann schon gerne wissen, ob ich dadurch unbeabsichtigte Änderungen habe, beziehungsweise wenn ja, wo. Dabei helfen Tests dann enorm. Das heißt, für mich ist der Sinn von Tests weniger, zu zeigen, dass der Code *jetzt* funktioniert (da bin ich mir tatsächlich auch ohne Tests relativ sicher), sondern sicherzustellen, dass er es auch in der Zukunft tut, auch wenn größere Änderungen anfallen.
@@thenativeweb ich stimme dir jedoch nicht zu. Denn auch schweißen wird nicht unter den selben Bedingungen angewendet. Die Materialien, Form, Erreichungsgrad und vieles mehr - jedesmal was anderes. Daher. Es kommt auf die Erfahrung an. Auf die Meister Qualität. Genauso wie in der Entwicklung. Danke
Lädst du einen Teil deiner Videos eigt auch irgendwo (zB Spotify) als Wissenspodcast hoch? Gerade so ein Video in dem du nur redest und kein oder wenig relevantes Bildmaterial zeigst, wäre optimal ums beim Joggen oder Abends im Bett zu hören ❤
Es gibt mindestens zwei Voraussetzungen für den Einsatz von TDD: erstens, wie du es sagtest, man muss wissen, wo man hin will. Und zweitens: du musst deinen Chef davon überzeugen, geschätzt 20-30% mehr Entwicklungszeit einzuplanen und die ohnehin immer zu knapp bemessenen Deadlines über den Haufen zu werfen. Viel Spaß bei Punkt 2. :)
[gr] Die Frage ist, warum man das überhaupt diskutieren muss. Für mein Empfinden gehören Tests zum Sicherstellen der Qualität dazu, und das ist das, was von Kundenseite aus gefragt ist (Qualität). Natürlich zahlt kein Kunde explizit die Tests, aber bei dem, was Softwareentwicklung kostet, ist hohe Qualität praktisch nahezu immer erwünscht.
Insofern würde ich die Frage gar nicht aufmachen, denn dann diskutiert man nicht über Qualität, sondern über die Werkzeuge. Tests zu schreiben sollte IMHO so wenig hinterfragt werden wie Kommentare oder Dokumentation zu schreiben. Natürlich kosten sie trotzdem Zeit.
Die Frage ist: Wenn das 20-30% mehr sind als die ursprüngliche Schätzung - wo kommt diese Schätzung denn dann her?
Das Paradox von TDD: mehr Tipparbeit und spart trotzdem Entwicklungszeit. Wie geht das? Code eintippen macht nur 10% der Entwicklungszeit aus, 90% der Zeit verbringt man mit denken, debuggen, refaktorieren, etc. Durch TDD geht die Zeit fuer's Eintippen von 10 auf 15% hoch, weil man ja jetzt auch noch Tests schreiben muss. Aber die Zeit die noetig ist um zu debuggen, gruebeln, und auf den Code starren um zu verstehen warum genau er nicht funktioniert geht von 90% auf sagen wir mal 60% herunter. In der Summe sinkt die gesamte Entwicklungszeit dank TDD in diesem Beispiel von 100% auf 75%. Jeder Chef der Ahnung hat sollte daher darauf bestehen, das solide Entwicklungstechniken wie TDD verwendet werden. Weil das Geld spart.
Automatisiertes Testen spart im Vergleich zu manuellem Testen nach meiner persönlichen Einschätzung mindestens 50% der Zeit. Ob du die Tests zuerst schreibst oder nachziehst, macht dann keinen großen Unterschied. Man kann auch beim Nachziehen von Tests noch feststellen, dass der Code sich nicht gut testen lässt und ihn nochmal ändern. Und man kann auch ohne TDD nochmal refactorn, wenn schon alle Tests grün sind.
Bei jedem neuen Feature, dass ich einbaue, gehen immer alte Tests kaputt. Die Mehrheit davon muss einfach nur leicht angepasst werden, weil der Test zu spezifisch war und nicht zum neuen Feature passt. Das mag vielleicht nervig sein, aber es geht immer sehr schnell. Aber die paar Tests, die rot sind, weil das neue Feature nicht korrekt verdrahtet wurde, sind einfach Gold wert.
@@kevingoslar7543 Wenn man sinnvoll testet und die notwendige Routine hat, dann hast du wohl recht. Wenn man die orthodoxe Lehre des TDD verfolgt und für jede Trivialfunktion erstmal einen Test schreibt, dann vermutlich nicht.
@@xtra9996 Du hast Recht, man benoetigt Erfahrung um TDD richtig zu machen. Und wenn man es wegen mangelnder Erfahrung zu mechanisch macht, kann es ineffizient werden. Das trifft aber auf so ziemlich alles zu und ist damit keine besonders treffende Kritik von TDD. Da es keine gesunde Alternative zu automatisiertem Testen gibt, ist TDD also eine notwendige Trainingsuebung fuer Entwickler und Teams die zu wenig Erfahrung mit Testen haben (meiner Ansicht nach immer noch 80-90% der Industrie). Der Weg zum Software-Ninja ist also: zu wenig und zu spaetes schreiben von Test (z.b. erst nach manuellem Testen) ---> strenges TDD ---> mehr nuancierte aber immer noch umfassende Nutzung von automatischen Tests. In jeglicher Form ist TDD meiner Erfahrung nach aber schneller und effizienter als zu wenige Tests und zu viel manuelles Testen und Debuggen.
Beim Studium kommt es auch immer darauf an, an welcher Einrichtung man studiert. Die allgemeine Universität hat nicht den Anspruch, eine Berufsausbildung darzustellen. Sie schafft lediglich die wissenschaftlichen Grundlagen auf akademischem Niveau. Da ist es nachvollziehbar, daß mathematische Beweise für einen Algorithmus Inhalt der Auseinandersetzung sind. Erwarten würde ich allenfalls eine analytische Untersuchung, was verschiedene Arten von Tests leisten können und was nicht, auch das wieder in wissenschaftlicher Herangehensweise. Die Praxis erwirbt man nach dem Studium oder parallel in Eigenregie.
CV ist ähnlich (12/40:). Themen im meinem Informatik-Studium (mit Nebenfach-Pflicht) waren völlig sinnlos. Nichts für bereits Praxis-Erfahrene. - TDD: Funktionen/ Methoden gehen nicht mehr über etliche Bildschirm-Seiten, haben nur noch wenige Zeilen und der Compiler warnt bereits während der Entwicklung sehr aktiv; und Beta-Tester kann es auch nicht ersetzen.
Kann mich deinen Ausführungen fast vollständig anschließen.
Beim Prototyping braucht man tatsächlich Disziplin, geschriebenen Code wieder wegzuwerfen. Das ist nicht immer leicht.
Wenn ich in einer derartigen Untersuchungsphase bin schreibe ich daher tatsächlich fast ausschließlich Test-Code und nichts im main. Ich nutze dabei die Tests selbst schlicht als Vehikel, um einzelne Komponenten und Ideen direkt ausführen zu können und bei Bedarf dann mit den bekannten Test-Werkzeugen aus dem Projekt auch mit Daten zu befeuern.
Dadurch dass ich auch beim Prototyping nur Tests produziere, fällt es dann wieder recht leicht im Anschluss, diesen einfach wieder wegzuwerfen ;)
Das Argument das ich am häufigsten höre, warum auf TDD verzichtet wird ist der erwartete hohe Aufwand. Ich bin der Meinung, dass wenn man TDD nur direkt auf APIs anwendet, sei es Framework APIs oder auch direkt REST-Endpoints, der Aufwand tatsächlich deutlich geringer ist, als wenn ich nach der eigentlichen Umsetzung erst mühsam die Tests implementiere. APIs kann ich i.d.R. innerhalb eines Projektes nämlich immer auf die gleiche Weise testen, was den Aufwand und die Wartbarkeit deutlich erhöht.
[gr] Ja, das stimmt.
Was aber auch gerne vergessen wird, ist, dass der primäre Zweck der Tests gar nicht ist, die Korrektheit *jetzt* sicherzustellen, sondern *langfristig* dafür zu sorgen, dass man nicht aus Versehen etwas in seiner Semantik ändert, was man gar nicht ändern wollte … das ist aus meiner Sicht der viel, viel gravierendere Aspekt.
Wobei man da noch mal genau zwischen TDD und Tests unterscheiden muss.
Eine kleine Zwischenfrage: Du sagst: “Für jede Zeile Code soll ein Test geschrieben werden.” Das meinst Du doch im übertragenen Sinne, richtig? Werden nicht eher Testfunktionen für einzelne Funktionen, Routinen und Classen (Objekte) geschrieben?
[gr] Jain … was ich meine, ist folgendes: Du sollst nicht für jede einzelne Zeile einen dedizierten Test bauen. Es darf (zumindest gemäß TDD) kein Code existieren, für den Du keinen Test brauchst. Also anders formuliert: Code sollte nur maximal das machen, was auch durch die Tests abgedeckt ist. Du solltest nicht schon eine Abkürzung oder einen Spezialfall irgendwo einbauen, für den Du noch keinen Test hast.
Denn wenn Du das machst, dann hast Du Codezeilen, für die es keinen Test gibt. Und wenn Du dann an denen etwas änderst, beeinflusst das unter Umständen, wie sich Deine Funktion / Klasse / whatever verhält, ohne dass das über einen Test abgesichert wäre.
Klarer?
@@thenativeweb Ja, so klingt das schon besser. Mir ging es eher um die Formulierung. Aber es geht auch darum, wie weit man das TDD treibt. Man kann neben den einzelnen Testfunktionen für einzelne Funktionen, Routinen usw auch noch eine weitere, übergeordnete Schicht an Testfunktionen schreiben, die die Zusammenarbeit der einzelnen Elemente testet, und dann noch eine weitere Schicht darüber. Wie auch die Aufrechterhaltung der Funktionalität bei gestressten Systemen.. usw, usw,...
Sehr gut aufgearbeitet. :)
[gr] Danke schön 😊
Jetzt kommt wieder der Grünschnabel mit der absolut dümmsten Frage vermutlich =D Man schreibt den Test vor der eigentlichen Software?. Aber wenn ich doch garnicht weiss wie der Code aussehen wird wie dann eine Testumgebung schaffen ?
[gr] Das ist überhaupt keine dumme Frage - tatsächlich habe ich mich das vor Jahren auch gefragt. Und die Frage ist so essenziell, dass ich denke, dass es noch mehr Menschen gibt, die sich das fragen … und deshalb kommt demnächst ein Video zu dem Thema 😊
[gr] PS: Okay, ich kann "demnächst" etwas konkretisieren: In zwei Tagen, am Montag … 🎉
@@thenativeweb Ja Mega =P Vielen Dank dafür. Ich weiss nie wie mein Code vorher aussieht oder wie ich genau an ein Problem rangehen wenn ja noch nichts da ist. ich bin aufjedenfall gespannt =)
[gr] Danke ☺️
@@S3R43o3 [gr] Morgen früh um 8 Uhr ist es soweit: th-cam.com/video/H943sC8r7nQ/w-d-xo.html
Eine weitere Sache warum TDD schwierig ist, du brauchst Erfahrenes Personal die a) das kennen und b) darauf bock haben. Da ja Tests of gar nicht oder kaum in Unternehmen zum Einsatz kommen geschweige den von TDD gibt es sehr viele Entwickler die es nicht kennen. Und wenn du einen Entwickler das aufzwingst worauf er persönlich keine Lust hat und es nur als Last ansieht, kommt auch am Ende das gleiche Resultat.
Und ja TDD wird echt überbewertet wenn man das paar Jahre mal gemacht hat. Man kann es ja dann parallel mit CodeCatas üben. Ich habe so eine Pi mal Daumen Regel. Wenn du dir vorstellen kannst wie der Test dazu aussehen würde, reicht echt schon aus :D
[gr] Die Frage ist, ob wenn Tests gefordert werden, jemand sie aber grundsätzlich ablehnt, ob das dann die richtige Person für diese Aufgabe ist … wer es ablehnt, weil sie / er es nicht kennt, kein Problem: Das lässt sich ja lernen. Aber die Bereitschaft sollte schon da sein, sonst hat man ein anderes viel gravierenderes und tiefer liegendes Problem im Team als "keine Tests".
Und was gerne vergessen wird bei den Tests: Der Sinn von Tests ist nicht (oder nur sehr bedingt), sicherzustellen, dass das, was man jetzt baut, auch funktioniert. Sondern sicherzustellen, dass der Code auch in der Zukunft noch funktioniert, nachdem Änderungen oder Erweiterungen vorgenommen worden sind. Quasi wie ein Sicherheitsnetz.
@@thenativeweb schon, aber ich kenne jetzt wenig Entwickler die sagen "Boah testen ist das beste was es gibt" dafür kenne ich Entwickler die mir dann eher sagen "Ich habe das ganze We verbracht das neue Framework zu lernen, es ist voll geil"
Richtigen Personen ist eh bei unserem Beruf schwierig zu finden und wir müssen halt mit dem ARbeiten was wir die Resourcen her geben. Ich nutze gerne TDD sage nur dass es nicht einfach und manchmal kontraprodukt sein kann.
Aber ich sehe total ein , mittlerweile ist es bei mir auch so dass ich den code danach messen kann ob ich dafür einfach tests schreiben kann oder nicht. TDD mach ich auch nur dann wenn ich vorher das Problem genau kenne.
Ich studiere momentan Informatik und da spielt automatisiertes Testen absolut keine Rolle. Generell kommt die Themen Code Strukturierung, Code Qualität und Software Architektur viel zu kurz.
Wer hat gesagt das Informatik etwas mit Programmieren oder etwa dem 'guten' Programmieren zu tun hat?!?
Wo studiertest und was genau? Formale Verifikation sollte eigentlich immer noch Teil der Ausbildung sein. Unit-Tests lernt man sicher irgendwann an der FH.
Hi, ich habe deinen Kanal erst gefunden und finde, dass du das echt super machst. Freue mich auch schon auf diese Folge. Gehst du bei den Tests auch auf Programme wie Wallaby.js ein? Deine Meinung würde mich schon interessieren. Mach weiter so. Freu mich schon auf die Folge.
Viele Grüße!
[gr] Vielen Dank, das freut mich 😊
Auf konkrete Tools gehe ich in diesem Fall nicht ein, es geht mehr um den konzeptionellen Ansatz. Was konkret Wallaby.js angeht, kann ich leider aber auch nichts dazu sagen, weil ich es - außer vom Namen her - nicht kenne und daher auch keine Erfahrung damit habe.
@@thenativeweb Alles klar, vielen Dank für die Antwort. Freu mich auf das Video morgen!👍
@@thenativeweb gib Wallaby mal ne Chance. Es ist ein Traum. Die kürzesten Feedback cycles die man haben kann.
@@NilsEckelt Super Tipp! ich nutze seit langem InfinitTest, prima dass es jetzt auch andere Tools der Art gibt!
4:10 Achtung: Proof of concept code wird meiner Erfahrung nach oftmals nicht verworfen, sondern zum Produkt. Diese Entscheidung wird dann vom Management getroffen. Ist also eine Falle.
[gr] Das ist dann aber ein Fehler in der Unternehmenskultur / der Handhabung / vom Management - das macht den Rat ja nicht weniger wahr.
Insofern ist nicht der Rat, so zu arbeiten, eine Falle, sondern die (leider allzu häufig) gelebte Kultur.
Option 3: I am a simple man. I see Golo, I click.
[gr] Awwww 🥰
Ich find's schon aberwitzig, dass man im Studium diese testgetriebene, beweisartige (wissenschaftliche) Arbeitsweise nicht wirklich lernt und generell recht wenig programmiert.
Heise hat erst gestern einen Artikel zur "Zukunft des Informatikstudiums" in Form eines Interviews mit dem Vorsitzenden für die Informatiklehre an deutschen Unis veröffentlicht. Also ist schon ziemlich gruselig, was der alles von sich gibt. Da schau ich doch tausendmal lieber Golo zu 😂
[gr] Ja … ich bin da auch etwas konsterniert: Auf der einen Seite habe ich schon durchaus ein paar Sachen im Studium gelernt, die ich nicht missen wollen würde, und mir ist auch klar, dass speziell das Studium an einer Uni eher theoretisch ist und mehr auf die Grundlagen abzielt, aber auf der anderen Seite finde ich es doch erschreckend, was alles nicht Bestandteil des Studiums war, beziehungsweise wie unausgewogen das teilweise war. Und, wie sehr von den Interessen einzelner Professor:innen das geprägt war …
Wie auch immer: Ich freu' mich auf jeden Fall sehr über Dein Lob 😊
Code löschen ist doch sehr befreiend. Und schreibt man nicht alles drei mal? Einmal um das Problem zu verstehen, einmal um die Lösung zu verstehen und es beim dritten Mal richtig zu machen?
[gr] Genau das 😊
Wenn ich schon weiß, dass der erste Entwurf eh Mist sein wird, warum gebe ich mir dann Mühe, den in allen Ecken sauber zu machen? Dann doch lieber erst mal einen Quick'n'Dirty-Durchstich, lernen, Erfahrung sammeln, dann wegwerfen und auf Basis des Gelernten viel fundierter eine zweite Fassung bauen.
Ironischerweise geht das unterm Strich auch meistens viel schneller, als wenn man die erste Fassung beibehält und dann versucht, daran herumzuschrauben …
Natürlich kommt das einem Anfänger, vielleicht auch noch im Web-Bereich, oft so vor als wäre das Problem der testgetriebene Ansatz. Mit der Erklärung schadet man aber eigentlich nur sich selbst. Ein paar kleine Tipps für Dich:
Wenn eine Funktion einen Parameter mehr benötigt, fügt man diesen über ein strukturiertes Refactoring hinzu, Default ein neutrales Element. Löschen ist noch einfacher. Das ist überhaupt kein Problem mehr heutzutage, dauert keine zwei Sekunden und alle Tests sind auch gleich angepasst. Wenn die Tests vorher funktioniert haben sollten sie nun auch noch funktionieren, denn ein Refactoring ändert nur die Struktur, nicht das beobachtbare Verhalten.
Wenn Du wie erwähnt hunderte Tests für eine Funktion hast ist die Funktion eindeutig zu groß.
Wenn Du ein Problem nicht verstanden hast war die Vorbereitung nicht gut, vielleicht hast Du auch die Testfälle vorher nicht als „Shopping-List“ niedergeschrieben.
Und nun stell Dir vor Du hättest Dir keine Gedanken über mögliche Testfälle gemacht und merkst erst kurz vor Schluss was Du alles vergessen hast!
Die Fehlerquote in meinem Team ist recht hoch, es wird auf mangelnde Tests, bzw. kein TDD verwiesen. Ich meine aber, dass der Großteil der Fehler passiert weil die Entwickler die Anforderung nicht verstanden haben. Die Qualität des Codes ist meist tadellos, aber es fällt den Leuten oft schwer sich in die betriebswirtschaftlichen Abläufe von Anfang bis Ende einzuarbeiten. TDD würde hier genauso sauberen, fehlerfreien Code liefern, der halt dann immer noch nicht tut was die Geschäftsleitung erwartet.
ich stimme "so halb" zu - wenn man code benutzen kann (was für den manuellen test zwangsläufig so sein muss) dann ist er zwangsläufig auch testbar
Deine Einwände gegen TDD sind genau die, die mich von TDD abhalten. Ich muss doch erstmal lernen, was ich da eigentlich mache. Aber die Idee im Hintergrund sorgt für einfache Funktionen auf der untersten Ebene, in der es letztlich keine Abhängigkeiten mehr gibt - und schon gar nicht zu geisterhaften injected Dependencies, für die man extra Testframeworks und aufwendige Mocks verwenden müsste! 😫🤦♀️
Hey Golo - heute sind wir einer Meinung.
Leider bin ich nicht in Teams wo viel automatisch getestet wird.
In meiner Firma wird gerade das Thema angegangen.
TDD ist wirklich wichtig, aber es ist auch teuer.
Man sollte TDD wirklich da einsetzen, wo wirklich wichtige Funktionen bzw. eine wichtige Businesslogik Bestandteile sind.
Andere „nicht so wichtige“ Funktionen, kann um Kosten etwas zu relativieren normal testen und nicht TDD zu verwenden.
LG
Marcus
[gr] Ja, das stimmt. Es gibt Dinge, bei denen stehen Kosten und Nutzen in keinem Verhältnis. Entweder, weil die potenziell möglichen Fehler so trivial sind, dass sie ohnehin sofort auffallen würden. Oder weil es so schwierig ist, ein gutes automatisiertes Test-Setup hinzubekommen, dass man sich überlegen muss, ob sich das lohnt …
Insofern: Ja, das ist richtig für mein Empfinden. Aber: Ich erlebe es leider zu häufig, dass von Vornherein genau damit argumentiert wird. Mir wurde mal von einem Unternehmen gesagt, sie würden nicht testen, weil ihre Entwickler so gut seien, "die machen keine Fehler". Ironischerweise kam diese Aussage in einem Gespräch auf, in dem es darum ging, wie sie ihre Qualität verbessern könnten … finde den Fehler 🤣
@@thenativeweb 🤣🤣🤣🤣
Solange das Unternehmen den Fehler selbst nie einsieht.
Es gibt keine Fehlerfreie Software.
Ja und es ist soooo unterschiedlich.
Leider noch nicht überall angekommen, dass Testen mehr Vorarbeit erfordert, im Nachhinein aber eine imense Qualitätssteigerung ist, die kostengünstiger sein kann/wird.
Ich empfinde TDD als Mittel um gut strukturierten Code zu schreiben. Ganz einfach weil man so unbeschwert ein Refactoring betrieben kann. Als ich ohne Tests mit PHP arbeiten musste konnte ich zusehen wie mein Code verrottet ist... natürlich hat sich das Unternehmen stets selbst am meisten für Qualität gelobt...
Aber hast schon recht, es löst das Problem nicht, es kann nur dabei helfen. Ich hab das Gefühl das auch da die Menschen so ein Allheilmittel suchen. Man muss ja nur... Spoiler: Dies wird es nie geben. :D nirgendwo!
Hast du eigentlich ein fortgeschrittenen Video über automatische Tests? Also vielleicht auch weniger technisch, und mehr konzeptionell.
[gr] Wir haben schon mal ein paar Videos zum Thema "Testen" gemacht, die in die Richtung gehen dürften, was Du suchst:
- Tests - wozu überhaupt? th-cam.com/video/Mjr-iQ-_umU/w-d-xo.html
- Tests: Unit, Integration & Co: th-cam.com/video/A7ej4cgwgRk/w-d-xo.html
- TDD: th-cam.com/video/71nLhdZuMk0/w-d-xo.html
- Privaten Code testen, wie: th-cam.com/video/MZ76Haup3XY/w-d-xo.html
- Wie testen nicht funktioniert: th-cam.com/video/t2GO0ijzGvY/w-d-xo.html
Vielleicht ist da ja etwas für Dich dabei - falls nicht, sag gerne noch mal Bescheid 😊
Mist, am 17. erst? Das sind ja noch 3 Tage :)
[gr] Vorfreude und so … 😉
Hehe, das dachte ich mir auch. So eine provokante These ... und man muss warten.
TDD ist halt ein Werkzeug, das zum Anwendungsfall passen muss. Es handelt sich nicht um einen pauschal anzuwendenden Programmierstil.
Hallo, ich habe ebenfalls im privaten einige Systeme mit TDD entwickelt und als Programmieranfänger, der noch nich an großen Projekten mitgewirkt hat, dieses Werkzeug auf sich wirken lassen. Deine Ausführungen, zum Thema dass TDD manchmal überbewertet ist, sollten eigentlich selbstverständlich sein. Der Professor, ,der Anwendungsentwicklung in Verbindung mit TDD lehrt, geht genau diesem Grundsatz nach. Es macht wirklich überhaupt keinen Sinn, ins Bllaue hinein zu coden. Erst muss man sich ein klares Bild über das System machen, welches entwickelt wird. Je größer diese Systeme werden, desto mehr Zeit wird dabei natürlich vergehen. Aber die EInsicht von ihm, wenn man n-Tests geschrieben hat und all diese gehen positiv durch. Kann man zum derzeitigen Zeitpunkt sagen, man hat eine stabile und gute Software implementiert laut Tests, die man vorher definiert hat. Gerade das TDD verlangt eigentlich schon, dass man sich erstmal mit der Problemstelleung befassen muss, bevor man auch nur eine Zeile Code schreibt.
10/10 Punkte 😉
Thanxxxxx
Ich weiß jetzt schon das mir Golos Aussage diesmal leider nicht gefallen wird 😢 das wird eine harte folge für mich...
[gr] Vielleicht schaffe ich es ja doch noch, Dich zu überraschen … wer weiß 😉
[gr] Und? Liegen unsere Ansichten tatsächlich so weit auseinander wie erwartet?
@@thenativeweb nein zum Glück nicht😅 In der Problemfindungsphase probiere ich oft herum ohne konkreten code zu schreiben, bis ich dann ungefähr verstanden habe wie es funktionieren müsste und lege dann mit TDD los. Aber bis heute bin ich davon ausgegangen, das meine TDD Erfahrung noch nicht ausgereift genug ist um von anfang an mit TDD zu beginnen. Stichwort "expolratives testing", wo man wohl tests für bestehende Interfaces schreibt, um herauszufinden wie sie funktionieren, wären da vielleicht ein Ansatz. Aber gut zu wissen das selbst die besten, wie du, hier ähnliche Probleme haben wie ich kleines Licht. 😇
Ich hab den Titel des Videos gelesen und wusste sofort dass ich dich hier finden würde ^^
Das ist der Grund, warum sich TDD ab und zu anfühlt wie "einen Marathon zu laufen - mit der Sichweite eines Mikroskopes -" ...man sieht den Wald vor lauter Bäumen nicht. Sehr ungünstig, wenn man sich dann zudem noch verläuft xD
In dem Moment wo das letzte D als "Design" gelesen wird lassen die Diskussionen nicht lange warten ;)
Ich finde das ist wie in der Kunst: Da gibt es viele Stile und wenn der Maler was kann kommt immer was "schönes" Raus (umkehrt nützt den Untalentierten wie ich es bin auch die beste Technik wenig).
Aber klar gibt es einfacherere und schwierigere Techniken.
Für mich ist TDD durchaus Anfängergeeignet - einfach nur deswegen weil es relativ leicht zu lernen und anzuwenden ist (bitte keine bösen Rufe - nicht vergessen: einfach zu Lernen und schwer zu Meistern - wenn man sowas gefunden hat ist es praktisch immer ein Hit).
Aber es ist nicht der einzige Weg guten Code zu schreiben und es ist auch nicht jeder ein schlechter Entwickler der bei TDD nicht nur positive Erfahrungen gemacht hat ;)
---
PS: wer ein bischen Spaß haben will (gibt dabei durchaus was zu Denken) und wem die Diskussionsserie die damals auf THHs "Test-induced design damage" damage (dhh.dk/2014/test-induced-design-damage.html) zu langatmig ist, dem kann ich das Video hier: vimeo.com/110554082 und für extra LOLs dann die Antwort von Uncle Bob blog.cleancoder.com/uncle-bob/2014/11/12/PutItInProduction.html empfehlen ;)
[gr] Oh ja … TDD als "Test-Driven Design" lesen, und dann kannst Du Dich am Besten einfach nur möglichst schnell rausziehen, Popcorn holen und zurücklehnen 🍿🤣
Ich habe ein paar Tage über dieses Video nachgedacht.
1. Der Inhallt trifft 100% meine Meinung
2. Der Titel ist trotzdem Click Bait, sorry. "Überbewertet" impliziert dass jemand eine Bewertung hat, die höher ist als... als was? Es gibt keine objektive und allgemein gültige Bewertung von TDD, also clicken die Hater und die Fanboys gleichermaßen auf den Link.
Ein besserer Titel wäre "TDD hat Grenzen der Nützlichkeit" oder "TDD ist kein Allheilmittel" o.ä.
TDD ist tatsächlich keine gute Idee. ich habe es gezwungener Weise schon verwendet. Und ich habe auch kein Problem damit. Nur ist der Code der dabei rauskommt, meistens fürchterlich. Und es verbraucht eine Menge Zeit, die man besser in guten Code stecken sollte. Ich schreibe auch Tests. Sehr viele sogar. Aber die Testen keine Methoden, sondern Funktionalität. Das spart Zeit und ist letztendlich das einzige was zählt. Das was hinten rauskommt muss der Spezifikation entsprechen. Wie der Code da hinkommt ist irrelevant. Also teste ich das auch nicht.