Ich sage wie es ist: 59€ sind viel zu wenig für all die Informationen, die du uns hier wöchentlich über den Zaun wirfst. Danke für diesen großartigen Beitrag!
Hallo Golo, vielen Dank für die beiden, wieder sehr praktischen und sehr gut erklärenden Videos zu TDD. Dieses Tutorial gehört nun sogleich zu den Videos, das ich meinen Seminar- und Kursteilnehmern an Herz legen werde. Super. Weiter so!
TDD mit gelockten Services oder DBs fänd ich schön zu sehen. Da struggle ich immer und ziehe die Tests nach. Habe parallel diese Übung in Golang und Typescript mit gespielt. Katas hatte ich total vergessen. Danke. Hat Spaß gemacht.
Hi @Golo, du hast mir als TM voll aus der Seele gesprochen, ich versuche immer TDD nach deinem Paradigma zum Einsatz zu bringen, danke für die zusätzlichen Argumente.
Ich hadere schon seit Jahren damit, in meinen Projekten TDD einzusetzen, weil ich nie verstanden habe, wie ich erst die Tests und dann den Code schreiben soll. Jetzt ist mir das etwas klarer geworden, auch wenn ich noch nicht weiß, ob ich das bei komplexeren Funktionen umsetzen kann. Das waren auf jeden Fall gut investierte 2 Stunden.
Vielen Dank für das Video, sehr gute und symphatische Einführung in das Thema TDD! Ich fand auch die Kata dafür gut gewählt - sehr interessant und gut gelöst von Dir, plus sie war ein sehr gutes Beispiel für das Schreiben, aber auch für die Relevanz von Tests. Da ich erst vor wenigen Tagen zufällig auf euren Channel gestoßen bin, freue ich mich nicht nur auf kommende Videos, sondern auch darauf, noch viele "alte" Videos anschauen zu können :)
Mir als Coding-Dojo-Evangelisten sind ein paar Dinge aufgefallen. 1. Red-Green-Refactor hat einen Sinn. Diese Kleinteiligkeit des Vorgehens ist genau dafür da um diese Denkmuster zu üben und zu schärfen, die du zugegeben schon verinnerlicht hast. Das macht dieses Video zu einem tollen Anreiz um zu sehen wo die Reise hingehen soll, aber es zeigt nicht so gut wie man da wirklich hin kommt. Du sagst das zwar und auch mehr als einmal, dass dir deine Erfahrung bestimmte Dinge "vorgibt" und du liegst ja auch richtig damit, aber als "Einstieg" ins Thema TDD oder Coding Katas, sind mir da zu viele Abkürzungen genommen. 2. Zu den Tests selbst. a) Ich bin kein Freund mit Schleifen zu testen. Zugegeben... Node/Mokka macht das besser als zum Beispiel ein JUnit4 (5 hab ich leider noch nicht angefasst), aber ich hab da meine Schwierigkeiten mit. Das mag ein erlernter Reflex sein, weil ich viel mit Java arbeite/gearbeitet habe. b) Es ist ja schön, dass roboter so eingestellt ist, dass beim ersten roten Test nix mehr geht. Das ist im Node-Kontext auch sinnvoll. Nur dann sollte man es vermeiden beim Schreiben Tests "oben drüber" einzuführen. Dann ist nämlich nicht ersichtlich, ob man mit dem hinzugefügten Code gerade die alten Testfälle kaputt macht. Das kann im Zweifel aber eine wichtige Information sein. c) Das Stoppen bei einem roten Test ist für mich nur im Node-Kontext wirklich sinnvoll. Aus meiner Java-Erfahrung heraus, finde ich aber noch immer sehr befremdlich, dass Node die Tests in Reihenfolge ausführt. Ich hab schon mehr als einmal gesehen, dass deshalb Testfälle von einander abhängig waren. Das war nicht unbedingt beabsichtigt, ist aber eben einfach passiert, weil die Entwickler*innen nicht darauf geachtet hatten. Da kommen wir auch wieder zu den Schleifen zurück. Die sorgen dafür, dass Tests immer in der gleichen Reihenfolge ausgeführt werden und wenn dann Dinge wie DOM-Manipulation drin auftauchen (oder andere globale Elemente), wird das schnell schwierig. So. Nu aber weiter gucken. Ich hab ja noch 25 Minuten offen.
Wieder ein sehr lehrreiches Video über einem Bereich der auch von mir bisher eher vernachlässigt wurde. Vielen Dank dafür! Anstatt mit if / (else) sollte man hier vielleicht besser mit switch / case arbeiten. Außerdem bin ich kein Freund von zu vielen return(s) innerhalb einer Funktion. Ich habe mal gelernt besser im Idealfall nur einen "Eingang" und einen "Ausgang" zu verwenden. Ich hatte übrigens ein paar Probleme mit dem "Roboter", der ein paar Problem-Fälle nicht korrekt angezeigt hat. Erst im verbose mode bekam ich eine Erklärung für meine "malformed package.json". Auch meine nodejs Installation habe ich jetzt von v14 auf v16 upgedated, nachdem es hier wieder ein (replaceAll) Problem gab.
[gr] Danke für das Lob und Dein Feedback 😊 Was mehrere Returns angeht, kommt die Empfehlung, nur eins zu haben, IMHO aus Sprachen wie C, wo man sich um die Speicherverwaltung von Hand kümmern muss. Mehrere Returns machen es dort viel schwieriger, zu erkennen, ob jeglicher Speicher wieder sauber freigegeben wurde. In Sprachen, die mit einer Garbage-Collection arbeiten, ist das Argument aber hinfällig, insofern spricht hier für mein Empfinden auch nichts gegen mehrere Returns, insbesondere dann nicht, wenn sie dafür sorgen, dass weniger Komplexität durch weniger Verschachtelung entsteht. Wegen des Roboters: Ja, er läuft nur mit der aktuellen LTS-Version, das ist bei uns generell die Philosophie, dass wir keine älteren Versionen unterstützen (zumindest nicht in dem, was wir als Open-Source freigeben). Wenn es darüber hinaus Probleme gab, freuen wir uns natürlich auch über einen Bugreport auf GitHub 😊
Danke für die beiden interessanten und lehrreichen Videos zum Thema TDD. Generell bin ich von ihren Videos sehr angetan. Toll wären bei Gelegenheit weitere TDD-Beispiel, die sie schon erwähnt haben: "Datenbank", "Dateisystem" und auch "Netzwerk". Ich denke, ich bin nicht der einzige, den/die solche Beispiele interessieren würde :). Nachdem ich mich ebenfalls erst mit Visual Studio Code vertraut mache (als jahrelanger Sublime Text user), könnten sie mir bitte verraten, welches Theme für VSC sie verwenden? Danke :)
[gr] Vielen Dank für das tolle Feedback, und über kurz oder lang wird es sicherlich noch eine fortführende Folge zu dem Thema geben 😊 Was das Theme angeht: Das ist das „Atom One Dark“-Theme, angelehnt an den Editor Atom, den ich vorher verwendet habe 😉
@@thenativeweb sehr gut, dann bin ich gespannt auf weitere Videos zum Thema TDD (und natürlich auch auf ihre anderen Videos) und danke für den Hinweis auf das VSC-Theme 😊
Super Video, vielen Dank! Und da du es angeboten hast, hiermit gerne: "Wie würdest du TDD bei einer Komponente angehen, die auf eine Datenbank zugreift?" ;-)
Hallo Golo, auf deinen Punkt zu Beginn des Videos zu sprechen zu kommen, ob man jede Zeile Code einer Funktion testen muss. Dazu kann ich bereits sagen, es kommt immer darauf an, was genau die Funktion machen soll. Besteht diese aus sehr wenig Code und soll nur eine Aktion ausführen und stecken in ihr mehrer Aktionen drin. Somit kann es durchaus passieren, dass man für eine Funktion nicht nur einen Test schreiben muss oder sollte.
Sehr schöne und einfache Darstellung wie man mit TDD starten kann, vielen Dank dafür. Ich habe bisher eher Schwierigkeiten mit der Vielfalt der verschiedenen Test-Frameworks gehabt, ist Mokka Eure Empfehlung oder macht es Sinn, gerade am Anfang, sich doch eher mit einem anderen Werkzeug vertraut zu machen?
[gr] Vielen Dank für Dein Feedback 😊 Was Mocha angeht, haben wir damit seit rund 10 Jahren sehr gute Erfahrungen gemacht (und kennen auch die Schwächen). Es gibt ein paar Alternativen (historisch wohl am ehesten Jasmine, heutzutage eher Jest), die für uns aber aus verschiedenen Gründen nicht relevant oder interessant sind. Unterm Strich dürfte es aber ziemlich egal sein, insbesondere wenn man noch nicht so viel mit Testen zu tun hat, welches man verwendet. Konzeptionell sind die am Ende alle gleich.
Sehr schön, hat mir tatsächlich weitergeholfen, wie man das am besten angeht. Ich als Hobby-TDDler war da noch nicht so firm. Hab dir ja mal geschrieben, dass ich da was Größeres machen will und werde es da mal umsetzen. Wenn es so weit ist, dass man was zeigen kann, kann ich dir ja mal den link zum Repo geben und du / ihr könnt ja mal Analysen machen und Zeigen, wie ihr fremden Code analysieren würdet (wenn ihr das überhaupt wollt). Wird erst einmal ein "Framework" für alle. Ich hab mir gerade auch mal dein hübsches Gesicht auf meinem 4K-Fernseher gegeben. War leider gar nicht mehr sooo hübsch. Die Videos nimmst du mit einem iPhone auf oder? Vielleicht solltest du dir doch eine richtige Kamera beschaffen. Dann kann man gerade die langen DDD-Videos auch im Bett genießen, ohne bei bewegten Gegenständen / Personen nur noch Pixelmatsch zu sehen. Am Fernseher liegts nicht, der skaliert eigentlich sehr sehr gut hoch. Tat mir um dein hübsches Gesicht wirklich leid. Aber der Code war trotzdem gut zu lesen. :D
[gr] Vielen Dank für Dein Feedback, freut mich, dass das Video hilfreich war 😊 Was Dein Feedback bezüglich der Bildqualität angeht: Die regulärenVideos, in denen ich mit dem Rücken zum Schreibtisch stehe, zeichnen wir mit einem iPhone 11 Pro auf. Das gilt aber nicht für diese langen "X in Y Minuten"-Videos: Die nehmen wir mit der Logitech StreamCam auf - und die hat eine deutlich schlechtere Qualität als das iPhone. Von daher müssten wir das eventuell mal umstellen …
Ich habe früher auch die zu testende Funktion bzw. Klasse direkt in einer neue Datei geschrieben. und diese dann in die Tests importiert. Ich habe aber irgendwann festgestellt, dass mich das gerade am Anfang, wenn ich vielleicht noch gar nicht weiß, ob ich etwas wirklich behalten möchte, langsam macht. Seit einiger Zeit schreibe ich daher die zu testende Feunktion bzw. Klasse direkt in die Testdatei und das Verschieben in die richtige Datei ist dann eine Refactoring-Schritt, der kommt, sobald ich 3-4 Tests geschrieben habe und mir sicher bin, dass ich die Klasse so beibehalten will.
@@thenativeweb Gerade mit JetBrains-IDEs ist das besonders interessant. Ich schreibe den Klassennamen in den Test, drücke [Alt]+[Enter], dann nochmal [Enter] und die IDE hat die Klasse für mich erstellt.
Die Fälle, bei denen die Methode von externen Abhängigkeiten wie Filesystem oder Datenbank abhängig ist, wäre echt sehr interessant als Video. Gerne auch in C#.
Die Abhängigkeiten mockst du. Heisst, du baust "Fakeklassen" wo du das echte Verhalten simulierst a la "db = this.createMock(DB::class).addMethod("select").willReturn(new Array(1,2,3,4,5))" und sie statt der echten Klasse benutzt, statt wirklich in der DB / FileSystem rum zu lesen/schreiben. Und man injected die Klassen dann im constructor / den Methoden. Also statt class MyClass { constructor() { this.db = new DB(); } } => class MyClass { constructor(DB db) { this.db = db;) } } Das tut man übrigens mit allen externen Klassen (dependencies). Das hat den Grund, dass du nur eigenen Code in UnitTests testen willst und nicht externe Klassen (die schon ihre eigenen separaten Tests haben). Im Fall von DB gibt es zwar auch QueryTests, wo man eine Testdatenbank hochfährt, mit immergleichen Daten befüllt (fixtures genannt) und damit testet - macht aber kaum jemand, weil arschaufwändig. Genauso FileSystem - ja man kann auf "file_exists()" testen. Das kommt sogar häufiger vor, als DB Tests - aber im Endeffekt testest du damit eigentlich nur die native (C# or whatever) Funktion/Methode "writeToFile(content, filename)". Man testet da eher, mit welchen Parametern der Mock aufgerufen wird a la: "this.assert(myWriteToFileMock).willBeCalled(1).withParams(["foo", "bar.txt"])". Jetzt alles PseudoCode. Aber ab da wird dann TDD auch unschön, weil sowie du mal die "echte" DB Klasse umschreibst und das select() eine andere Signatur oder Rückgabe hat, darfst dann nicht nur die reinen DB-Tests anpassen, sondern alle anderen Tests auch, wo du sie als Mock benutzt. Und das kann schnell sehr ermüdend werden.
@@thenativeweb Ja also UnitTests ohne Mocks sind eigentlich nur die halbe Miete. Weil ohne kommst du in der "echten Welt" (also keine Codingübungen) zu allermeist nicht aus. Und da habe ich auch selber zum Teil Probleme mit: Was mockst du alles? Models die nur setter/getter beinhalten? new Date() - wo man keine Factory drum herum schreiben will? Was macht Sinn im gemockten Code zu testen - also bringt Anzahl der Aufrufe / Params eigentlich was, oder sollte dies nicht der Integration- oder Acceptancetest dann übernehmen? Mal son Video mit "nicht für Neulinge, sondern 2-3 Level Up" fände ich auch gut ;) P.S. Ich habe da jetzt zwar meine Meinung zu, aber andere Sichtweisen zu erfahren, dass man diese dann auch überdenkt - ich denke, das gehört zum immer währenden Lernprozess dazu.
Wie viele Stunden habt ihr an "roboter" gesessen, damit die EInrichtung eines TypeScrict-Projektes & Co. "nur" 10 Minuten braucht? Das ist ja Wahnsinn, wie aufwändig das offenbar ist.
[gr] Stunden? 🤣 Okay, ernsthaft: Das ist die inzwischen dritte von Grund auf neu konzipierte Fassung, die Du im Video zu sehen bekommen hast, und rechnet man mal alle drei großen Versionen mit ihren jeweiligen Updates und so weiter zusammen, dann reden wir da nicht über Stunden, sondern über viele Wochen (10 bis 20 Personenwochen stecken da locker drin, eher mehr).
@@thenativeweb Das ist ja furchtbar. Es heißt aber auch, dass das Setup für ein Typescript-Projekt SO aufwändig ist, dass es sich lohnt, diese 10-20 Personenwochenstunden aufzuwänden und damit unterm Strich Zeit & Geld spart. Und selbst trotz dieses Aufwandes dauert das Setup noch etwa 8 Minuten zu lang.
[gr] Ja, denn wenn du mehrere 100 Projekte hast, addieren sich die Zeiten ja durchaus auf… Wobei man der Fairness halber dazu sagen muss, dass der Roboter weitaus mehr macht als nur das mit TypeScript.
Stellt sich immer noch die Frage ob man bei X Entwicklerstunden und bei Y geplanten Features zum Schluß das bessere Ergebnis erhält, als ein Ansatz mit weit weniger detaillierten Tests. Wenn man nicht fertig wird oder mehr Entwicklerstunden in der Summe braucht ist das auch nicht hilfreich. Da rechne ich jetzt die Aufwände für Bugsupport aber auch Wartung der Tests bei Featureänderungen mit ein.
@@thenativeweb Ja, das habe ich eine zeitlang auch gedacht. Leider kommt man nicht an die Person vorbei, die am längsten in der Firma ist und die arbeitet seit jeher ohne Tests (und ohne Commit Messages, im Grunde weiß man gar nicht, was er macht). Ich versuche es für mich umzusetzen, mehr kann ich aktuell nicht tun. :(
[gr] Spontan musste ich da an „Getting Things Done When You‘re Only A Grunt“ von Joel Spolsky denken (unbedingt lesen!): www.joelonsoftware.com/2001/12/25/getting-things-done-when-youre-only-a-grunt/
[gr] Fehler entstehen auch dort, wo Du etwas zwar bedacht hast, es dann aber aus Versehen falsch implementierst (oder durch den Einbau eines neuen Features das Verhalten eines bereits vorhandenen unabsichtlich veränderst). Tests sind kein mathematischer Beweis und keine 100%-Garantie, aber sie helfen schon sehr vor Fehlern im Lauf der Zeit.
Ich fand das VOD mega, hab mich schlapp gelacht bei der HArdcodierten 100 und dem Array im Array das du ja noch gesehen hattest. Was ich noch denke du hast am ende doch recht wenige totals gehabt. PS: Test von Methoden die auf die DB zugreifen denke ich ist auch ne nette sachen weil diese sollte es ja nicht geben aber grad bei altcode ist es ohne refactoring nicht möglich sowas zu testen.
@@thenativeweb Ich persönlich hätte da auch andere Vorstellungen, aber erstens verdient die Software richtig Geld und zweitens ist der Kunde nun mal König. Abgesehen davon sind über Jahrzehnte alle Versuche, es im "akademischen Sinne richtiger" zu machen, kläglich gescheitert ... ;-)
@16:50 "Error: …should end with a period." - Der dämliche Compiler sollte anbieten, den "period" doch selber (meinetwegen auch nur temporär) zu setzen : )) - COBOL- und Pascal-Compiler waren auch immer solche Kracher.
[gr] Haha 🤣 Ja, das ist so eine Sache … wenn der Compiler / sonst ein Tool weiß, dass irgendwo ein Semikolon / Klammer / Punkt / … fehlt, warum ergänzen sie es dann nicht automatisch?
Hallo Golo, besteht die Möglichkeit, dass du uns deine tsconfig.json und deine .eslintrc.json zur Verfügung stellst? Ich wollte dein Beispiel einfach mal nachcoden und lernen. LG Sebastian
[gr] Klar - am einfachsten kopierst Du Dir die einfach aus einem unserer zahlreichen Open-Source-Module, zum Beispiel von hier: github.com/thenativeweb/assertthat
