Warum TDD (Test-Driven Development) überbewertet ist // deutsch 

[gr] Dein letzter Satz fasst das Ganze so schön zusammen: "Tests sind Werkzeuge und keine Religion." 😊

[gr] Danke für das Lob 😊

[gr] Vielen, vielen Dank - das ist echt lieb 😊

[gr] Vielen Dank 😊

[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.

[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.

[gr] Danke schön 😊

pragmatisch oder prank-matic ? 😀

[gr] Danke schön 😊

[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.

[gr] Danke schön 😊

[gr] Danke für Deinen Kommentar 😊

[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…

[gr] Awwww 🥰

[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…).

[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!

[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.

[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.

[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.

[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.

[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.

[gr] Danke für die Anregung 😊

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.

[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.

[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,...

[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.

[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

[gr] Danke für den Link (beziehungsweise die Anregung zum Googlen) 😊

@@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.

[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."

[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.

[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 😊

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.

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 ☺

[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.

[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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-H943sC8r7nQ.html

[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? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Mjr-iQ-_umU.html - Tests: Unit, Integration & Co: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-A7ej4cgwgRk.html - TDD: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-71nLhdZuMk0.html - Privaten Code testen, wie: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-MZ76Haup3XY.html - Wie testen nicht funktioniert: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-t2GO0ijzGvY.html Vielleicht ist da ja etwas für Dich dabei - falls nicht, sag gerne noch mal Bescheid 😊

[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 …

[gr] Vorfreude und so … 😉

Hehe, das dachte ich mir auch. So eine provokante These ... und man muss warten.

[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.

[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 ^^

[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 🍿🤣