Hi David, auch wenn es nicht häufig der Fall ist, bin ich da aber zu 90% einer anderen Meinung! Das einzige, wo ich dir zustimme ist, dass es sich als kontraproduktiv erweist, wenn man UnitTests erst im Nachhinein schreibt. Das ist immer problematisch, da der Code teilw. noch nicht einmal testbar ist und man ihn aufbereiten muss, damit er testbar wird. Aber eine pauschale Aussage dieser Art zu treffen, halte ich für Maga-Gefährlich! Stell dir mal vor, da kommt ein sehr junger Programmierer zu seinem Chef und sagt: "Der Thielke hat gesagt, man braucht keine UnitTests und langfristig kosten die 5x soviel Zeit". Ich kann mir nicht vorstellen, dass dann irgendjemand sagt: "Yolo, mach die trotzdem!". Mal ein Beispiel aus der Praxis: wir hatten mal hier einen Monolithen ohne UnitTests etc. nach ca. 2 Jahren war der Code unwartbar und hatte mehr Bugs als Features. Dann haben wir die gleiche Funktionalität in eine Anwendung nach der CoCo-Architektur überführt und mit TDD kombiniert. Und siehe da, die Anwendung ist sehr stabil, hat kaum Bugs und unsere Tester zweifeln an sich selbst, weil die keine Bugs finden. Neue Features? Kein Problem, sind relativ schnell drin. Und wir sprechen hier von einer Anwendung mit 90k+ LoC! Diese Anwendung ohne UnitTests wäre reiner Selbstmord! Und nein, ich stelle nicht die CoCo-Architektur über UnitTests. Das ist halt eine perfekte Ergänzung und wenn man beides zusammen einsetzt, wird es richtig cool. Aus eigener Erfahrung kann ich auch sagen, dass ein Feature umso teurer wird, wenn keine UnitTests existieren. LG Sergej
Hey Sergej, 1. Meine Aussage war nicht pauschalisiert, ich habe differenziert gesagt das: - Unit Tests sehr gut sind um komplexe Bereiche abzusichern - Der Aufwand der Wartung häufig unterschätzt wird - Unit Tests schädlich sind, wenn Sie eingesetzt werden um die erzeugten Probleme einer schlechten Architektur zu "verdecken" 2. Ich habe nicht gesagt das man keine Unit Tests braucht, sondern das man die Kosten (1+2+4) gegenüber dem Nutzen abwiegen muss und deshalb nur relevante Stellen testen sollte um dort die Funktion zu gewährleisten 3. Ich prognostiziere mal, das ihr TDD (wie Du selbst gesagt hast) nur punktuell eingesetzt habt. Die bessere Stabilität kommt meiner Vermutung nach von der sauberen Architektur (CoCo reduziert die Komplexität auf ein Mindestmaß, folglich werden weniger Fehler gemacht) und nicht zwangsläufig durch die Tests 4. Aus meiner Erfahrung versichere ich Dir, ein Feature wird umso teurer je schlechter die Architektur ist - mit Unit-Tests hat meiner Meinung nach nur begrenzt etwas zu tun. Und in einem Punkt widerspreche ich Dir ganz klar: Eine ordentliche Architektur ist für die Stabilität immer wesentlich wichtiger als Tests! Lg David
David, natürlich ist eine ordentliche Architektur federführend und weniger Fehleranfällig. Keine störendere Redundanz, bessere Widerverwendbarkeit, etc. Aber dennoch bleiben einzelnen Teile der Software über zum Testen. Viele logische Fehler können im Vorfeld durch UnitTests (nicht immer) abgefangen werden, die vielleicht durch die weiteren Tests fallen würden. Ich denke, das Gesamtpaket ist die Lösung. Was ist wichtiger? Qualität, die jedes Audit besteht. OderSoftware, wo vielleicht ein Teil X ungewiss ist, obwohl die Architektur stimmt.
@@DavidTielke Gute Architektur kommt auch durch Testdriven development da man sich vorher gedanken machen muss was man eigentlich erreichen will. Welcher Leiderprobte Untermehmer hat dich bezahlt um dieses Video rauszuhauen? :D Ne im Ernst ich teile deine Meinung mit der 1-2-4 Regel (so hab ich das ehrlich auch noch nicht gesehen) aber es macht für mich sowohl zeit- als auch kostentechnisch einen grossen Unterschied ob ich die Zeit in einen automatisierten Test stecke oder dumm die Applikation (am besten noch im Produktivsystem) zu debuggen. Dann ist nämlich nicht nur meine Arbeitszeit ein Kostenfaktor sondern auch der nicht gemachte Umsatz im Onlineshop. Das nicht produktive Arbeiten mit einer Anwendung die Fehler enthält ist ebenso ein Kostenfaktor der langfristig auch mehr schadet und mehr Geld kostet. Zudem ist der psychische Druck auch nicht zu unterschätzen. Fehler die schnell gefunden werden müssen sind besser zu beheben wenn man die Anwendung noch nicht produktiv hat. Kranke Mitarbeiter sind auch ein Kostenfaktor :)
@@sebastianforster7992 Das ist einfach nur falsch. Kann ich aus der Praxis sagen. Architektur wächst nicht aus Test Driven Development. Sondern Architektur definiert die Schnittstellen und dann kann mit Test Driven Ansatz eine solche Schnittstelle implementiert werden. Wir verwenden bei uns z.B. die Clean Architecture (Onion) mit all ihren Vorteilen. Die ist aber nicht aus der Testgetriebenen Entwicklung entstanden sondern das Konzept musste vorher durch entsprechende Projekte und Interfaces erstellt werden und danach konnten die einzelnen UseCases mit Testgetriebener Entwicklung umgesetzt werden.
@@pinguincoder du wirst mir sicher zustimmen, das es extrem schwer ist eine nicht getestete Komponente nachträglich mit Tests zu versorgen deutlich schwieriger ist als von vornherein mit den den Tests zu arbeiten. Testbarer Code ist immer viel leichter wieder verwendbar als nicht getesteter Code. Das ist meine 20 jährige Erfahrung. Und darum gehts am Ende um Zeit und Kosten zu sparen.
Wenn man bei einer Änderung vom Code viele Tests anpassen muss, sollte man überlegen, ob man SOLID begriffen hat..Tests sind such dazu da, um zu begreifen was man eigentlich programmiert
Eine gute Architektur ermöglicht es, Unit-Tests so zu schreiben, dass sie sich möglichst wenig überlappen und somit bei einer kleinen Code-Änderung auch nur wenige Tests angepasst werden müssen. Durch Code-sharing zwischen Tests (DRY) kann der Umfang der nötigen Anpassungen minimiert werden.
arbeite seit gut 20 Jahren in diversen Sprachen mit Unittests. Und das Argument "erschweren Refactorings" habe ich bisher auffallend häufig von Leuten gehört, die selbst keine Erfahrung im Testsschreiben haben. Ich finde günstige, fehlerarme Refactorings werden gerade durch Unitests ermöglicht. Und viele meiner Kollegen, die wissen wie man testbaren Code schreibt, sind auch der Meinung.
Also wir hatten das Maintenance Problem nicht. Wenn wir wirklich "große" Änderungen machen mussten, dann lag es daran, dass uns der fehlgeschlagene Test auf Problem durch einen Change hingewiesen haben. Hies also entweder die neue Businesslogik anpassen oder die Alte. Bisher haben die Tests bei uns immer Seiteneffekte in anderen Komponenten aufgezeigt, die nur über einen Kompletttest aller Prozesse aufgefallen wären.
Hallo Andre, interessant das du es "Maintainance Problem" nennst, weil viele haben es hier genau so verstanden wie Du und ich frage mich wie man das Video so verstehen konnte. Die Aufwände hat man immer, weil genau das wollen wir mit den Tests bezwecken, aber sie sind halt da. Das diese Aufwand sinn macht, gar keine Frage aber er ist eben da. Es ging vielmehr darum, dass wenn man es in den falschen Projekten anwendet, man in Teufels-Küche kommen kann. Das hier war keine verallgemeinerte Aussage über Unit Tests :) Gruß David
@@DavidTielke Das die ganze auch Schief gehen kann, ist klar. Ich wollte einfach mal meine Erfahrung mitteilen. Wie du auch schon in anderen Videos gesagt hast, man sollte sich überlegen/ wissen was man tut und nicht einfach drauf losen "programmieren".
Gute Unit-Tests zu schreiben ist eine eigene Kunst, die viel zu selten Beachtung findet. Du beschreibst hier genau die Tests, die ich anfangs voller Enthusiasmus selbst geschrieben habe: Man testet fast alles, 99% Coverage als Ziel, indem man jedes Detail bearbeitet, vor allem das Unwichtige. Und am Ende testet man leider nicht das, was man eigentlich testen möchte, nämlich die Funktionalität des Features, sondern man testet, ob ein Knopf einen Methodenaufruf triggert (also das UI-Framework), oder ob der Aufruf von Methode X die Methoden Y und Z in dieser Reihenfolge aufruft (also Implementationsdetails), ob man in eine gewisse if-condition rein kommt, wenn man Daten ganz besonders formt (also den exakten Flow), ob in irgendeiner Liste, die ein Implementationsdetail ist, ein Wert vorhanden ist, den man vorher rein gesteckt hat, etc. (also interne Datenstrukturen). Oft testet man, ob das Programm den exakten Fluss hat, den man sich ausgedacht hat. Und natürlich ändert sich der auch mit jeder Änderung der Funktionalität und schon ist man in der Falle, die du beschrieben hast. Andere Tests testen nicht mal irgendwas, was rein oder raus geht, sondern die laufen einfach nur durch und sind immer grün. Warum? Weil man den unendlich großen Fehler begangen hat, dem Management die Test-Coverage zu zeigen und das plötzlich 60% oder mehr Test-Coverage fordert und dann die Devs jeden schmutzigen Trick nutzen, um die automatisch erstellte Statistik hoch zu bekommen. Man testet nicht, man triggert die Zähler von Cobertura, Codecov, usw. Der Grund ist nicht, dass man Unit-Tests hat. Man testet die falsche Unit. Was man eigentlich testen möchte ist, z.B. wenn ich eine Transaktion abschließe, dass eine Abbuchung vom Lager stattfindet und ggf. eine Mail getriggert wird und ich möchte z.B. dass in der Mail die Posten enthalten sind. Der Rest des Weges ist mir aber recht egal. Meine Unit sind nicht alle Methoden auf dem Weg dahin, sondern meine Unit ist der Geschäftsfall, das Feature, das Requirement. Das erklärt vielleicht auch den zwischenzeitlichen Hype um "BDD" (Behavior Driven Development) als scheinbaren Kontrast zum "TDD (Test Driven Development). Dabei machen beide im Idealfall exakt das Gleiche. Wenn man natürlich die Implementation einer besonderen Map testet, oder eine Methode, die eine Email-Adresse auf Gültigkeit prüft, dann sind Unit-tests auf dem Level von ein oder zwei Methoden oder einer Klasse und sehr isoliert und eigenständig also problemlos. Wenn ich aber die Business-Logik meines Programmes teste, dann ist die Einheit unter Test nicht das technische Detail der involvierten Objekte, sondern der Geschäftsfall. Das wird immer wieder falsch gemacht, weswegen dann Videos wie deines kommen, die Unit-Tests in einen Topf werfen, in den sie nicht rein gehören. Jetzt kann man natürlich sagen: "Das ist ein Integrationstest, kein Unit-Test" und da muss ich widersprechen: Ein Integrationstest ist es nur, wenn ich die Integration mehrerer Systeme teste, nicht, wenn ich z.B. teste, ob wenn ich eine High-Level-Methode triggere, dort, wo ein Call in ein Email-System raus gehen sollte, auch ein solcher aufschlägt. Ich platziere meinen Test an der Boundary meines Systems, ein Integrationstest wird es erst, wenn die Boundary zwei Systeme überspannt, wenn ich also teste, ob etwas, was in System 1 geschieht, von System 2 verarbeitet wird. Meine Mocks sind an den Schnittstellen und die sollte ich vorrangig testen. Und wenn ich die entsprechend gut teste, dann komme ich ebenfalls auf eine hohe Coverage, nur eben versperre ich mir nicht den Weg zur Weiterentwicklung indem ich unnötige Details teste. Was Tests aber schonungslos offenlegen, besonders während eines Refactorings oder einer Änderung, ist wenn man zu lange Abhängigkeitsketten hat, weil man zum Beispiel interne Datenstrukturen leakt. Etwas, wie: "getBlaManager().getFoo().getBar().add(junk)" hat wohl schon jeder gesehen, das ist ein Klassiker, wo "foo" und "bar" Details sind, die man nicht sehen will, weder im produktiven Code, noch im Test. Hierzu sei auch gerne das "Law of Demeter" genannt, welches man vielleicht nicht allzu streng auslegen sollte, aber immer im Hinterkopf behalten muss, wenn man wartbare Software schreiben will. Das Law of Demeter hilft auch, Test-Units zu bekommen, die sich weniger mit den Interna beschäftigen, sondern mehr mit der API, mit der Domäne. Und leider, das ist auch oft der Fall, gibt es immer noch Antipatterns, wie das Singleton, die das Testen wirklich unnötig schwer machen. Wenn ich ein Objekt habe, welches Bestellungen entgegen nimmt, und eines, welches aus einer Bestellung eine Email macht und eines, welches eine Email verschickt, dann möchte ich die doch austauschen können, gerade um mich nicht mit den Details einer Implementation herum schlagen zu müssen, sondern damit, ob der Geschäftsfall so abläuft, wie vorgegeben. Tatsächlich wird man genau dann mit Tests schneller, wenn die sich nicht in Details verlieren. Ich kann mit einer wirklich guten Testsuite sehr hart refactoren mit wenig Sorge, dass etwas unerwartet kaputt geht. Mit einer schlechten Test-Suite refactore ich mehr Tests als Code. Du redest vom Aspirin-Problem: Dein Problem, die schlechte Entwicklungsgeschwindigkeit wegen Tests sind ein Symptom und dein Aspirin ist: Tests wegschmeißen und auf wenige Bereiche, die hoch kritischen zu beschränken. Damit öffnest du aber haufenweise Lücken, die mit manuellen Tests und langsamen Integrationstests gefüllt werden, oder noch schlimmer Tests mit Point+Klick-Automation (Selenium. etc), die chronisch brüchig sind. Die Ursache ist aber: Schlechte Wahl der Test-Units, also mangelnde Ausbildung der Programmierer.
Habe genau die gleichen Erfahrungen gemacht. Mocks die testen ob Funktionen aufgerufen werden verwende ich gar nicht mehr. Habe gute Erfahrung mit fakes gemacht, um Zugriffe aufs Filesystem, Registrierung etc. weg zu kriegen. Finde die Begriffe unit test und Integration test nicht nützlich. Würde eher von low und high Level tests reden, oder von kleinen, mittleren und großen tests wie sie es bei Google machen.
An der Stelle möchte ich noch auf dieses Video hinweisen: "TDD, Where Did It All Go Wrong (Ian Cooper)" Leider wird dieser Hinweis immer gelöscht, wenn ich den RUclips-link poste, also selber suchen.
Danke, danke, danke! Genau das! Was aus meiner Sicht zum Beispiel auch müßig ist, ist zu testen falls die Datenbank nicht antwortet. Ich sage immer, dass man sehr schnell merkt wenn der Datenbank Server weg ist, das muss ich nicht testen. Deswegen sind auch 95% Coverage Blödsinn.
Mocks sind nur dafür da, mein System von Systemen zu entkoppeln, die nicht in meiner Verantwortung sind. Der DB Server ist in meiner Verantwortung, das SAP System aber nicht. Meine Tests müssen laufen, auch wenn die Kollegen Wartungsarbeiten haben.
Ich finde es übertrieben zu sagen dass die Unittests mehr Schaden als Nutzen anrichten. Ich gebe zu, dass es Fälle gibt wo Tests zu Problemen führen können, wenn man sich nicht sicher ist was man genau testen will. Oder in einer Experimentellen Phase steckt und man ein Outcome sich erstmal erarbeiten muss. Aber, dass diese einen Schaden anrichten, konnte ich bisher nicht feststellen. Auch, dass die Entwicklung schneller gehen soll mit den Tests, habe ich nie gehört. Eher geht es ja darum, dass man mit den Tests einen Fehler schneller nachvollziehen kann. Es kommt natürlich auf die Architektur drauf an. Aber es gab schon viele Fälle wo ich ein Fehler gemeldet bekommen habe, dann habe ich die Tests dazu geschrieben die diesen Fehler nachstellen und konnte es dann beheben. War oft der Fall wenn man mit externen APIs arbeitet wo sich auch mal der Response geändert hat. Klar 100% TestCoverage sagt nicht darüber aus dass die Software bugfrei ist. Aber es schadet bestimmt nicht wenn ich mir die Mühe gebe und wenigstens 70% Code Coverage habe. Die Tests haben halt das Problem, dass diese Fehler schon vorher unterbinden. Es ist schwierig zu messen wie unwirtschaftlich eine Software wäre ohne den Tests. Somit kann man auch schlecht sagen dass Tests nur unnötig Geld/Zeit kosten. Ich als Entwickler kann aber besser Schlafen wenn ich weiß dass 70% meines Codes mit wenigen Klicks geprüft werden. Trotzdem finde ich das Video gut weil man über etwas diskutieren kann ;) Viele Grüße
Hey, Die Aussage, das die Entwicklung schneller gehen soll mit UT, habe ich schon etliche Male gehört, wie im Video bereits gesagt meist weil die Entwickler glauben so die Vorgesetzten davon zu überzeugen. Was Du mit dem Nachstellen der Fehler beschreibst, ist ja ein komplett anderer Ansatz als das was ich hier beschrieben habe. Dort nutzt Du die Unit-Tests ja um die Anwensenheit des Fehlers zu zeigen und anschließend den Fix zu verifizieren. Absolut OK! Da ist meine Kernaussage nicht richtig rübergekommen: Ich halte Tests in den richtigen Situationen für super. Solange ich es einsetze um Funktionen zu verifizieren ist alles in Ordnung, sobald ich sie aber nutze um die Menge der Fehler in der Software in den Griff zu bekommen, wird es definitiv problematisch, weil ich damit das eigentliche Problem nicht löse sondern nur unterdrücke. Gruß David
Ah ok David, ja das stimmt. UTs benutzen um Fehler oder Misstände zu vertuschen!? Geht das? Das ist nicht deren Aufgabe. Auch die Software über UTs zu debuggen, ist in manchen Fällen fragwürdig. Dafür sind UTs nicht gedacht.
@@DavidTielke die Schnelligkeit kommt durch bessere Architektur weil man Sachen wiederverwenden kann die man vorher ausreichend getestet hat :) Ein über die Jahre falsch entwickeltes, abseits des gängigen Software Handwerkszeug Produkt wird man nicht schnell auf Vordermann bringen können. Es hilft aber langfristig eben keine neuen Fehler einzubauen und man ist sicherer bei kleinen und auch grossen Änderungen. Auch hier ist die Wiederverwendbarkeit entscheidend.
Mir sparen Unittest jede Menge manuelles Testen. Was ich hasse. Und was niemand bei jeder Änderung für alle Funktionen machen will. Natürlich testet man manuell bevor man es an die QAnoder den Kunden übergibt. Aber ich habe zu dem Zeitpunkt halt nicht schon 25 ,Al dasselbe Formular ausgefüllt.
Год назад+4
"Wir implementieren Tests, um funktionale Sicherheit zu bekommen." - das ist mMn zu kurz gesprungen. Ich implementiere Tests, damit ich zukünftige Änderungen mit der Zuversicht durchführen kann, dass bereits umgesetzte Funktionalität weiterhin - ehm - funktioniert. Und wie schafft man das? Indem Tests jetzt(!) darin helfen das Design zu verbessern. Wenn ich eins durch Tests gelernt habe, ist's, dass ich ohne (große) Angst vor dem Kaputtmachen von Funktionalität verschiedene Herangehensweisen an die Lösung ausprobieren kann. Das verbessert das Design enorm. Das macht es möglich, weitherhin Funktionalität zum Kunden zu bringen. Auch bei älteren Projekten. Wenn man feststellt, dass durch neue Funktionalität viele alte Tests angepasst werden müssen, muss man sich seine Tests mal genauer anschauen. Vielleicht wird das Falsche getestet - Als Stichwort: "Zustand statt Verhalten" TDD beats FDD (Fear Driven Design) anytime!
Hey Steffen, funktionssicherheit bedeutet auch, das die Funktion bei Erweiterungen abgesichert ist - von daher: mit der Aussage gehe ich mit :) Gruß David
Volle Zustimmung! Musste auch schon in einigen gescheiterten Projekten diskutieren, warum Tests uns grade nicht weiterhelfen. Nächstes mal werde ich deine Kopfschmerzmetapher anbringen, die ich sehr passend finde. Danke für deine Erklärung!
Hallo David, Danke für deine Sichtweise! Ich würde in deinem genannten Beispiel jedoch andere Ursachen folgern. Es wurde ein System entwickelt, welches mit zunehmender Entwicklungszeit sehr viele/immer mehr Bugs verursacht hat. Nun hat der Entwicklungsleiter darauf reagiert und festgelegt, dass für bereits bestehenden, ungetesteten Code Unit-Tests geschrieben werden sollen. Und dennoch hat dies kaum dazu geführt, dass in der weiteren Entwicklung weniger zusätzliche Bugs verursacht wurden. Liegt die eigentliche Ursache evtl. darin, dass mit zunehmender Entwicklungszeit immer mehr technische Schulden aufgebaut wurden? Und man die korrekte Zeitpunkte für Refactorings verpasst hat (sowohl für Software Design als auch Software Architektur)? Ich nehme an, dass in dem Projekt von Anfang an kein automatisierte Testkonzept/Testpyramide vorhanden war/ist. Sonst hätte es auch Unit-Tests gegeben. Unit-Tests alleine können sicherlich nicht dafür sorgen, dass die Funktionalität/Erweiterbarkeit sichergestellt ist. Schon gar nicht, wenn man Tests für Code schreibt, der von anderen Entwicklern vor langer Zeit geschrieben wurde. Da entstehen keine qualitativ hochwertigen Unit-Tests. Schon gar nicht, wenn der initiale Code "nicht testbar" geschrieben wurde. Am Produktiv-Code will man dann wenig ändern, da das System ja an sich fehleranfällig ist. Und dann werden halt Unit-Tests mit 10+ Mocks geschrieben, wo im Grunde e nicht wirklich etwas abgetestet wird. Da helfen Unit-Tests dann natürlich nicht weiter. Das liegt aber nicht an den Unit-Tests an sich, sondern, dass die Tests minderwertig geschrieben waren. Aber mit einer vernünftigen Teststrategie haben qualitativ hochwertigen Unit-Tests (damit meine ich, dass man Tests nicht nur wegen der Coverage schreibt) ihre Berechtigung. Auch wenn sie nur trivialen Code abtesten.
Hallo Johannes, sehr gerne! Versteh das nicht falsch, hast Du dir das Video wirklich angeschaut? Ich meine die Frage ernst, weil ich versuche (mal wieder) einige der Kommentare hier nachzuvollziehen. Ja, natürlich lag das an den technischen Schulden. Genau das habe ich doch gesagt, das diese Probleme nicht mit UT gelöst werden können sondern man zuerst die Ursache (Architektur, also technische Schulden) beheben sollte. Auch für den Rest den du geschrieben hast, bin vollkommen bei Dir. Aber nicht anderes habe ich doch in dem Video gesagt?!? Gruß David
@@DavidTielkeich denke das Problem ist, dass du in dem Video einen speziellen Fall nennst,indem Unittest tatsächlich der falsche Lösungsansatz waren. Besser wäre es in Salamitaktik Bereiche aus dem Monolithen rauszulösen, neu zu schreiben, diesmal gleich mit Tests und so nach und nach den Monolithen klein zu klopfen. Aber ich denke viele Entwickler und Chefs nehmen aus deinem Video mit: Unittests sind Zeitverschwendung. Das freut EntwicklerInnen, die keine Tests schreiben mögen, weil dies korrekt erwähnt gefühlt viel Zeit braucht. Da gibt man dem Kunden lieber Bananensoftware. Die Chefs sind glücklich, weil die Deadline gehalten wurde, der Entwickler kam wieder mal ohne Tests durch und dann entsteht über die Jahre schrottige Software.
Da bin ich ebenfalls anderer Meinung. Bei "einer" Änderung sollten niemals "ganz ganz viele" Tests fehlschlagen. Das klingt dann eher nach zu komplexer Logik. Gerade, weil ich immer die Unittests im Hinterkopf habe, hat sich auch die Art geändert, wie ich "entwickle". Unterbewusst achte ich bei jedem einzelnen Schritt auf die testbarkeit (Kein TDD). Das hat in den letzten Jahren für messbar höhere Qualität gesorgt. Aber sicherlich auch von der Branche abhängig.
Das kommt immer darauf an, welche Architektur Du verwendest und welche Grad an Qualität Du in der Anwendung hast. Wenn Du/Ihr sehr stark im Software Design seid, mag der Effekt nicht so stark sein, vorhanden ist er definitiv auch bei Euch, da bin ich mir sehr sicher, sonst hättet Ihr eine Kopplung von 0 und das ist unrealistisch. Wenn Du aber ein Team aus mehreren Entwickler hast, ist es ein höllischer Aufwand genau diesen Status mit allen Entwicklern aufrecht zu erhalten. Gruß David
Absolut. Ich sehe das ganze als Hassliebe bzw. notwendiges Übel. Sicherlich hat das einen moderat negativen Einfluss auf die Performance des Teams, aber das ist den Verantwortlichen wohl bewusst.
Den Verantwortlichen ist oftmals der Mehraufwand für das Schreiben der Tests bewusst, den Faktor der Wartung/Erweiterung ist leider nur wenigen Bekannt. Gruß David
Ja da stimme ich dir zu. Das hier angesprochene Problem ist das "Fragile Test Problem" und es gibt genug Methodiken um dem beizukommen und eine Testsuite zu bauen, die eben nicht bei kleinsten Änderungen auseinander bricht.
Ist doch prima, dass dir die vielen fehlschlagenden Tests anzeigen, wo die Anforderungen nicht mehr erfüllt sind und welchen Impact die "kleine" Änderung tatsächlich hat. Unit Tests sind dein Sicherheitsnetz beim täglichen Refactoring und nehmen dir die Angst auch unbekannten Code anzufassen und zu verbessern. Wann wird denn eine Software für Produktion freigegeben? Wenn alle Tests durchlaufen - die Tests sind praktisch die Requirements.
Moin, zuerst muss man mal differenzieren, was eigentlich mit Unittest gemeint ist. Unter "Unit", also einer Einheit, versteht so ziemlich jeder was anderes (nah meiner Erfahrung). Wenn man den klassischen Unittest als Test einer Methode sieht, die alles andere durch mocking services simuliert, dann gebe ich Dir zu 100% recht, die sind meiner Erfahrung nach zu 99% sinnfrei. Viel wichtiger ist das Zusammenspiel der Methoden und Komponenten, ich bin daher ein großer Freund von Integrationstests. Also von der UI oder WebAPI kommend bis zur Datenbank. Ja, das ist Aufwand, aber wenn man Umstrukturierungen vornimmt, müssen die Tests weiterhin laufen. Und gerade bei länger laufenden Anwendungen, wo der Ansprechpartner beim Kunden wechselt, die Entwickler ausgetauscht werden oder auch nur das Framework von Core 3.1 auf 6.0 migriert wird, helfend diese Integrationstests enorm.
Der Meinung bin ich auch. Und meist schreibt man sich eh eine Art Integrationstest, um den eigenen Kram schon mal in Betrieb zu nehmen. Wenn man das gleich "ordentlich" und automatisierbar aufsetzt ist mit wenig Zusatzaufwand viel gewonnen.
Unittests dokumentieren den Vertrag einer isolierten Unit (und setzen ihn durch). Das kann ein IT so nicht leisten. Natürlich darf man die Unit etwas größer schneiden, als record(String, String).
Danke David, meine Seele ist etwas leichter geworden...;) Hatte als technische Leitung irgendwann die Schnautze voll von der ganzen Test-Wartung. Is ja nicht nur so, dass das den Prozess verlangsamt, sondern dieser träge Balast auch immer wahnsinnig viel Kreativität der Entwickler kostet. Hatte mir bis dato immer nen schlechtes Gewissen einreden lassen, irgendwann mal den Großteil unserer Tests einfach in die Tonne geworfen zu haben. Gut zu hören, dass das wenn auch intuitiv getroffen, wahrscheinlich die richtige Entscheidung war...
nein. einfach nein. architektur und entwickler hätten gefixed werden müssen. die tests löschen um die failing tests loszuwerden ist wie bei problemen zur flasche zu greifen.
@@devbert1880 schau dir das Video noch mal an. Es geht nicht um Tests die failen, weil der Code Fehler enthält. Es geht darum, dass Code sich ändert und dadurch bei jeder Kleinigkeit die Tests selber fehlerhaft werden. Der hierdurch erzeugte Mehraufwand muss gerechtfertigt werden, statt mit religiösem Eifer 100% Testabdeckung zu predigen.
@@yannicwelle4021das liegt aber am schlechten Design, nicht an den Tests. Wenn du über schlechte Software Tests drüber legst, dann hast du den Fall. Wenn deine Klassen nicht viele Abhängigkeiten haben, dann sind auch die Anpassungen bei Codeänderungen üblicherweise nicht groß.
@@acboesefrau7729 ich kann nur wieder ermutigen das Video noch mal zu schauen. Das hängt weder 1dimensional an Code noch Architektur, sondern schlicht damit, dass Unit Tests extrem oft nachjustiert werden müssen. Zumindest wenn man agil auf ein bewegliches Ziel zuarbeitet...
Hallo, also diese Sichtweise empfinde ich nun als mehr als schwierig. Für mich bringen UnitTests ganz klar Vorteile: - Festklopfen der Logik: Man stelle sich eine Filter-View vor, die nach Anpassen mehrere Optionen eine URL erzeugt um damit neue Datensätze abzurufen. Dazu gibt es einen URL-Builder, der aus der gegebenen Menge der Parameter/Optionen eine korrekt formatierte URL erzeugen muss - Testen von Logik ohne die App zu starten. Man nehme hier den angesprochen URL-Builder bzw. den dazugehörigen Filter. Man müsste jedes Mal die App starten, ggf. auf irgendeine View navigieren und zig Parameter einstellen und dann im Debugger schauen ob das richtige Verhalten zu beobachten ist Das soll mal ein einfaches Beispiel sein das zeigt, dass recht häufig sogar Zeit gespart wird, da der Testaufwand während der Implementierung viel geringer wird. Ich implementiere nicht selten komplette Feature ohne die dazugehörige App überhaupt gestartet zu haben. Leider muss ich sagen, dass der angesprochene Nachteil - nämlich die vielen roten Tests - mir die Haare zu Berge steigen lassen. Wenn ich Code ändere - und seien es nur 3 Zeilen - und ich habe eine Menge Tests die auf einmal fehlschlagen... ja was bedeutet das denn? Da der Code kompiliert (sonst würden die Tests gar nicht laufen), wäre das Produkt letztlich so dann auch ausgeliefert worden oder wenigestens in den Test gegangen. Das heißt doch, dass ich unmengen Fehler produziert habe und sich viele Stellen eben nicht mehr so verhalten wie vorher. Na da sollte ich in dem Moment doch dankbar um jeden Test sein den ich habe und nicht die Arbeit verteufeln. Ich demontiere doch auch nicht den Feuermelder in der Küche, weil mich das gepiepse nervt. Etwas anderes ist es, wenn man völlig sinnbefreite Test schreibt. Ja man kann durchaus übelst komplizierte Tests zusammenschrauben die sehr schwer in der Wartung sind. Das ist dann aber eher ein Problem, dass man die Einheiten ggf. nicht klein genug geschnitten hat. Tests im Nachhinein schreiben kann man sich oft schenken, aber in Form von TDD würde ich niemals drauf verzichten wollen. Ich sehe es hier auch wie mein Vorredner Sergej: mir wird hier sehr stark pauschalisiert, dass UnitTests verzichtbar sind. Und auch sehe ich es so, dass UnitTests durch TDD einen Teil der Architektur mitbestimmen. Denn um testbar zu sein, muss ich bestimmte Entscheidungen in der Architektur treffen, die ich ansonsten ggf. nicht treffen würde (min. lose Kopplung).
Hallo Klaus, das mit dem Feuermelder ist ein super Beispiel: genau das meinte ich ja. Diesen Effekt will man ja erzielen. Aber wir müssen uns nicht alle vormachen, das Unit Tests uns schneller machen und in jeder Projektsituation sinn machen. Ich kenne zahlreiche Projekte wo genau diese Denkweise zum Scheitern des Projektes geführt hat. Es geht hier nicht darum, dass ich Unit Tests nicht mag, weil sie die Wartbarkeit kaputt machen. Es geht darum, dass mit der falsche Einsatz und die falschen Erwartungen dabei gegen den Strich gehen. Gruß David
Wir haben damals mit nem alten FatClient mit backend JunitTests und MockTests gehabt. Dann haben wir mit UI Tests angefangen und gemerkt, dass diese die einzigen Tests waren, die Fehler aufgedeckt haben. Seit dem schreiben wir nur noch UI Tests, trotz längerer Laufzeit. Als wir den FatClient dann durch einen WebClient abgelöst haben, haben wir direkt mit UI Tests begonnen unf wir hatten noch nie eine so hoche Stabilität. Klar, die Tests müssen auch gewartet werden und die durchlaufzeit ist selbst bei parallelen tests mit der kompletten build pipeline und aufsetzen der testsysteme bei etwa 7Std, aber das läuft im Jenkkns und alles ist automatisiert. Wir lieben es 👍
Im Frontend stimme ich dir zu. Da konfiguriert man häufig die Testumgebung mit. Eine kleine Änderung zerstört die Testumgebung und damit auch die Unittest. Im Java Bereich im Backend muss man allerdings nicht viel konfigurieren. Man kann sofort mit den Test beginnen. Wenn ich weiß, dass ich auch Tests schreiben muss, hat das einen Einfluss darauf wie überhaupt die Funktionen geschrieben werden müssen. Sie sind lesbar und wartbar. Aber wir haben wir auch aktuell, dass die Projektstruktur einfach zu komplex geworden ist. Auch Unittest würden hier nichts mehr bringen
Ja. Ja,ja und ja! Ich bin Backend-Entwicklerin und möchte nicht mehr ohne Tests coden. Die zeigen dir auch gleich, wo du beim Design in die falsche Richtung gehst.
Hallo David, vielen Dank für das tolle Video. Ich sehe es ähnlich, bei vielen feingranularen Unit Tests zementiert man das aktuelle Softwaredesign und erhöht den Aufwand für spätere Änderungen. Die 1-2-4 Regel fand ich ein tolles Bild, das ich noch nie gehört habe. Hast du dazu irgend eine Quelle? Ich denke das ist ein gutes Bild um genau die langfristigen Auswirkungen insbes. von unnötigen Erweiterungen, die wenig Mehrwert liegen zu zeigen.
Hallo David. Super Erklärung. Meine Meinung: Ja und nein. Ich baue immer mehr auf Tests auf und ja... Tests brauchen verdammt viel Zeit ABER die Fehlerquote und die "ah hab ich nicht bedacht"-Quote reduziert sich dadurch emens! Das ist ein super gefühl wenn man etwas entwickelt, es "anschließt" an die anderen Komponenten und es einfach nur geht. Außerdem bin ich überhaupt kein Fan von einfach so mal los drauf testen. Tests gehören nur dort hin wo man die Funktionalität von außen benutzt. Sozusagen auf Modulinterfaces und auf wichtige Algorithmen. Wenn ich mich nun auch noch an die Regel halte, dass ich keinen Sinn einer aufrufenden Funktionsschnittstelle verändern darf sondern nur eine Neue machen darf, dürfen sich bei Änderungen auch keine Tests ändern! Allerdings muss ich sagen, dass ich noch sehr wenig Erfahrung habe und ich daher nur Mutmaßungen treffen kann weil ich einfach noch zu wenig Szenarien miterlebt habe. Somit noch nicht weise genug bin.
Hallo Thomas, die von Dir angeführten Punkte sind unbestritten. Aber ich finde es schlichtweg falsch da von Zeitersparnissen zu reden, denn dafür sind Unit Tests nun einfach nicht da. Gruß David
Interessant wo kommt diese 124 Regel her? Ist die verifiziert? Was für Tests machst du stattdessen System Tests? Wie verhält sich das mit dem Aufwand zu den unit Test?
Muss leider radikal widersprechen. Ohne Unittests wären Änderungen an vielen Stellen gar nicht möglich, ohne reihenweise Bugs einzuführen. Vermeidet viele Probleme und spart enorm Zeit im Nachgang.
Hallo David, es ist schon eine Sichtweise. Ja, Du hast vollkommen recht, UnitTests erhöhen den Aufwand, und es ist falsch, dass wir durch UnitTests schneller werden. Da bin ich vollkommen bei Dir. Nur denke ich, das UnitTests, für eine wesentlich höhere Qualität der Software stehen. Ich denke, dass Du hier ein wenig zu kurz das Thema angehst. Es ist doch nur ein verschieben von Aufwänden, denn getestet werden muss immer. Und es wird doch für die Tester einfacher, wenn von vorn herein die meisten Fehler schon rausgefiltert wurden. Also wird der Aufwand der Tester reduziert. Zusätzlich werden diese Tests noch dokumentiert. Es ist ein zweischneidiges Schwert. Viel schlimmer mit TDD, denn diese Art kostet noch mehr Zeit und damit Geld. Aber es ist noch sicherer. Kommt auf die Anforderung an. Ja, Du hast recht, dass die Unit Tests in Folge von Änderungen, schief laufen können, aber genau das ist doch deren Aufgabe. Im Aufbau von Unittests habe ich Fälle überprüft und Fehler gefunden, die ich im normalen Flow nicht gesehen, bzw. nicht dran gedacht habe. Daher sehe ich UnitTests ein unverzichtbares Werkzeug für qualitative Softwareentwicklung. Und wir wollen doch qualitative Software erstellen.
Hallo Marcus, - Natürlich sorgen die UT für eine höhere Qualität - Ja, absolut es ist ein verschieben der Aufwände - ohne Frage. Ob die Aufwände nicht eher durch einen günstigeren Tester erledigt werden können, steht nochmal auf einem anderen Blatt - aber das war niemals die Aussage von mir. - Ja Test gehen bei Änderungen schief - vollkommen klar und das dann Aufwände entstehen und das gewollt ist, ist auch unbestritten aber die Aussage war ja, wenn beispielsweise die Architektur kaputt ist, löst ihr damit nicht das Problem sondern kaschiert es nur und die Zusatzaufwände bei der Wartung machen euch irgendwann platt. Rückwirkend betrachtet kommt das Video für sehr viele hier leider falsch rüber :) Gruß David
Ich habe da eine andere Meinung zu. Wenn Testing falsch gemacht wird, dann kommt es zu diesen Problemen. Während der Entwicklung schreibe ich Unittests um testgetrieben bzw. Test First sicherzustellen. Nachdem ich dann einen Integrationstest geschrieben habe bzw einen Akzeptanztest dann kann ich die Unittests, die wie ein Baugerüst eingesetzt werden (sog. Scaffholding Tests) nach dem "Bau" wieder zurückbauen und der Integrationstest verbleibt um die Funktionalität abzusichern. Für bestimmte Kernbereiche der Businesslogic (komplexe Berechnungen etc.) lohnt es sich die Unittests zu behalten. So mache ich das jetzt seit Jahren und kann dadurch das 1, 2, 4 Prinzip vermeiden
Hallo Nicolai, genau das war der punkt, das es zu den Problemen kommt, wenn die Unit Tests in der falschen Situation eingesetzt werden. Ich habe nie die Sinnhaftigkeit angezweifelt, aber wir schrieben sie um Funktionssicherheit zu bekommen, nicht um schneller zu werden und wenn es bereits Probleme gibt (falsche Architektur usw.) ist es mehr gefährlich als förderlich zu testen. Gruß David
Was ich immer gerne unit teste sind wirklich core components. E.G eine implementation von einer hashmap. oder auch das networking protocol um sicherzugehen das die compatibility immer gegeben ist
danke für deinen Standpunkt, ich bin aber anderer Meinung. Ich habe bei weitem nicht deine Erfahrung in der Branche aber Ich wollte trotzdem mal diese Diskussion "zwischenwerfen". Du sprichst ab ca. 3:00 von dem 1-2-4 Prinzip und das der 4-fache Aufwand der ursprünglichen Realisierung einer Funktionalität dann später für die Wartung "drauf geht". Als Beispiel sagst du, dass durch viele unit Tests die _Erweiterung_ der Software problematisch wird, weil man dann manchmal viele Tests fixen muss. Und genau in diesem Punkt bin ich anderer Meinung. Wenn man seine Software erweitert, warum muss man dann unit tests zu bereits implementierter Funktionalität fixen? Im nächsten Satz sagst du dann, dass strukturelle Änderungen eben das fixen von unit Tests zur Folge haben. Ja, da stimme ich zu, aber, dann sind ja nicht unit tests die Verursacher des Mehraufwandes, sondern ein schlechter Klassenentwurf, mangelnde oder ungenaue Anforderungen oder schlicht weg, dass sich Leute nicht an best practices, patterns halten und die Software von vorne rein schon zu eng/stark gekoppelt ist. Ich denke du hast in deinem Video ganz viele valide Punkte aufgezeigt, aber bist dann meiner Meinung nach zum Falschen Schluss gekommen, nämlich das unit Tests im Nachhinnein Mehraufwand verursachen, nur, weil man unit Tests benutzt. Am Ende des Videos gehst du nämlich genau auf diese Punkte ein. Ich finde nur den anfänglichen Teil und den Titel vielleicht ein wenig irreführend. Unit Tests dann, wie von dir in der Mitte beschrieben, als "band aid" Fix für ein viel größeres Problem zu benutzen ist quasi der letzte Nagel im Sarg. Und ich glaube darauf wolltest du wirklich hinaus.
Ich glaube man muss dazu erwähnen, dass man als Entwickler lernen muss wie man gute Tests schreibt. Ein Unternehmen besteht aber in der Regel nicht nur aus Senior Devs und ja viele Fehler führen auf schlecht definierte Anforderung, Architektur oder auch Tests die zu stark an die Implementierung gekoppelt sind. Prozesse wie Code Reviews, Interne Schulungen oder Code Katas könnten entgegen wirken. Man könnte sagen, dass Unit Tests dann schaden, wenn man Unerfahrene Entwickler hat, die als Aufgabe bekommen haben Tests für eine Legacy Code Basis zu schreiben. Aber Unit Tests an sich alleine sind gut, solange man weiß wie man diese schreibt.
Hey Daniel, der Wartungsaufwand entsteht sowohl bei Erweiterungen als auch bei Anpassungen. Eine Erweiterung kann ja entweder bedeuten, komplett neuen Quellcode zu schreiben oder eben bestehenden Quellcode um neue Aspekte oder Funktionen zu ergänzen - dann tritt genau dieses Phänomen auf. Ich habe derzeit beispielsweise ein Projekt, bei der über 45.000 (sehr gute) Tests geschrieben wurden und jetzt für das nächste halbe Jahr die Tests deaktiviert wurden, weil die Deadline aufgrund der komplexen Erweiterbarkeit durch die Tests nicht eingehalten werden kann. Anschließend werden die Tests dann in 4 Sprints nachgezogen - und das ist definitiv ein Problem :) Ja, genau das sollte die Kernaussage sein: UT zur Verifikation von Funktionen ist gut, schränkt aber die Erweiterbarkeit/Wartbarkeit ein (dessen muss man sich bewusst sein), werden Sie zur Reduktion von Fehlern eingesetzt bekommt man meist große Probleme. Gruß David
@@DavidTielke ja, da fehlt mir einfach die Erfahrung! Aber deswegen lohnen sich die Kommentare unter solchen Videos! Vielen lieben Dank für einen Einblick in das "echte leben". Ich hab viel gelernt!
Ich bin der Meinung: Unittests können Kontraproduktiv sein. Wie im Video erwähnt habe ich schon oft gesehen dass einfache Änderungen echt viele Probleme mit den Test cases hatten. Ich habe schon ETL Tests gesehen, die für bestimmte Tabellen explizit getestet wurden. Es war grausam neue Spalten hinzuzufügen, zu verändern oder zu entfernen... ein gutes Beispiel von gut gemeint, aber schlecht gemacht. Auf der anderen Seite hatte ich aber schon oft die Situation, in denen mich ein Unittest auf bestimmte Dinge aufmerksam gemacht hat. In der Objektorientierten Programmierung wird z.B. oft mit Seiteneffekten gearbeitet. Verändert man diese, sind die Auswirkungen auf andere Module nicht immer klar. Ein fehlschlagender Testcase ist da gold wert. Zuletzt steht aber die Aussage: Wer testet, schreibt besseren Code. Die Funktionen werden deutlich expliziter und übersichtlicher. Ich sehe in Projekten ohne Testabdeckung oft super lange, verschachtelte und unübersichtliche Funktionen (schlechtes Handwerk) und in Funktionen mit Testabdeckung wesentlich schöneres :D Fassen wir also zusammen: das notwendige Minimum macht den Mix
Das höchste Pain-Level mit SW-UnitTests erreicht man in der Functional Safety. Hier gilt das V-Model zu 100% und für UnitTests gelten zu dem sehr hohe Anforderungen an die CodeAbdeckung die i.d.R bei Branch-Coverage beginnt und bis zu MC/DC (Automotive/Industrial/Aero-Space, multiple conditon decision coverage) mit Nachweipflichten, Dokumentation, Impact-Analysen reicht...
Ich arbeite in der Entwicklung für leistungselektronische Systeme, die im Energieversorgungsnetz arbeiten. Wir machen keine Unit Tests. In der Regel schmiert alles relativ schnell ab, sobald etwas nicht funktioniert. Wir machen umfangreiche Systemtests an automatisierten Testständen, die jede Nacht mit dem aktuellen Build angestoßen werden. Der Rest ist Eigenverantwortung des Entwicklers. Bei den Bugs die zurückgemeldet werden, würden auch Unit Tests nicht helfen. Die beziehen sich eher auf die Gesamtfunktion des Systems. Unit Tests sind definitiv keine Pflicht.
Gerade in der startup phase sind unittests voellig sinnlos. Ich nutze eigentlich nur Unittests um automatisierte Programlaeufe zu erhalten die man mit interactiven Sprachen im REPL (Read-Eval-Print Loop) machen wuerde. Anstatt Unittests ist das Program mit vielen, vielen Assert Checks zu testen. An signifikaten Punkten immer wieder Invariant Checks einbauen die die logische Konsistenz ueberpruefen. Das ist das verschmelzen von Design By Contract mit Test Driven Design das funktioniert. Leider kennen viele gar nicht "Design By Contract" da Eiffel ja defacto ausgestorben ist. Da geht gutes Wissen vor die Hunde.
Also wir schreiben unsere Tests überwiegend entlang von Public API (zumindest beim Framework, da ist die Kritikalität grundsätzlich hoch). Dann können wir unter der Haube alles komplett refactorn und die Tests zeigen uns im Idealfall an, wo wir Verhalten geändert haben. Unit Tests im engeren Sinne vermeinden wir deshalb.
Hallo David, du sagst, dass neue Features bestehende Unit-Tests kaputt machen können und sie deswegen repariert werden müssen. Das klingt für mich, als hätte man zuvor das Single Repsonsibility Principle verstoßen.
Hey, das kann ein Grund sein aber natürlich kann es auch zeigen das die ursprünglichen Erwartungen nicht mehr passen. Letzteres ist ja genau das, was wir bezwecken wollen aber trotzdem erhöhen wir damit den Wartungsaufwand. Gruß David
Das Video kommt gerade richtig, denn ich s(chwi)tze gerade über den Unit Tests. Ich finde UnitTests im großen und ganzen sinnvoll. Sie haben mir schon geholfen, Schwachstellen im Code zu entdecken. Zum Beispiel indem man in Kombination mit Code Coverage entdeckt, dass bestimmte Bereiche gar nicht ausgeführt werden. Die 1-2-4 Regel kann sicher auch eine 1-3-9 sein. Insofern gebe ich David recht. ABER: Es gibt bestimmte Anwendungen, insbesondere wenn es sich dabei um Produkte im Medizinbereich handelt, die zudem in den USA vertrieben wird, wo Unit Tests zwingend vorgeschrieben sind. Die FDA lässt grüßen. Allerdings sind deren Unit Tests mit denen von z.B. Visual Studio nicht identisch. Die FDA meint nämlich das Testen von Units und nicht Unit Tests. Trotzdem wünscht sich die FDA eine 100%ige Code Abdeckung..... Mein Problem ist weniger das Schreiben der Tests, auch wenn es sehr aufwändig ist. Mein Problem ist: wie dokumentiere ich die Tests selbst und deren Ausführung/Ergebnis. Ohne VS Ultimate ist man auf 3rd Party angewiesen (z.B. ReSharper und seine Tools). Aber selbst dort ist der druckfähige Output mehr schlecht als recht. Also erstellt man sich eigene Tools, um die per Batch erzeugten wenigen Details einer Test-Ausführung irgendwie lesbar zu Papier zu bringen. Und das hält enorm auf! Als alleiniger Entwickler bin ich von allen Teilen der 1-2-4 betroffen. Und in Bezug auf den Kommentar von Ma Ma bezüglich trivialen Code: ich gebe dir recht, aber diesen zu testen erhöht meine Code Coverage Statistik und ist im Allgemeinen schnell implementiert ;)
@@MaMa-rc4eo "schnell" ist relativ. Wie erwähnt bin ich "alleine" unterwegs und schreibe und übersetze (DE->EN) "nebenbei auch noch die Hilfedatei, due Release Notes, Installationshandbuch , ... und erstelle auch Self-Learning Material. Für die Unit Tests hätte ich gerne einen Kollegen/in, aber seit Jahren passiert nichts...... Das, was mich am meisten aufhält ist die Recherche nach geeigneten Tools für die zusätzlichen CE/FDA Tätigkeiten. Oder zumindest jemand, mit dem man mal offline darüber chatten und sich austauschen kann. Letztlich höre ich hinterher immer, ob nicht noch dieses oder jenes möglich wäre, weil CE/FDA das auch noch gerne hätte oder in einem anderen Format. Um es von Anfang an richtig zu machen gibt es kein Geld. VS Ultimate, ohne es konkret zu wissen, könnte vermutlich vieles per Knopfdruck und ohne 3rd Party erledigen. Und es wäre aus einer Hand.
Hallo Markus, bin bei allen Punkten bei Dir, leider kommt aber wohl die Kernaussage nicht so wirklich rüber: Unit Tests sind sehr gut, aber sobald im Design Fehler sind und man anfängt die daraus resultierenden Probleme mit Unit Tests zu bekämpfen, gerät man in große Probleme :) Gruß David
Der Aspirin-Vergleich ist gut, ich sehe aber als Hauptursache die mangelnde Bereitschaft der Softwareindustrie, sich mit der formalen Verifikation von Software zu befassen. Solange dieser Zustand anhält, werde ich auf automatische Tests nicht verzichten wollen. Den genannten Nachteilen stimme ich zu, das Hochrechnen der 1-2-4 Regel widerspricht jedoch in krasser Weise meinen Erfahrungen, eher das Gegenteil ist der Fall.
Ich find den Aufhänger etwas merkwürdig. Es entspricht zwar auch meiner Erfahrung dass solche Ideen rumgeistern, aber man landet da dann doch schnell bei bei der Diskussion rund um die Architektur. Wenn das Anforderungsmanagement und die Architektur nicht passt, merkt man das woanders auch. Hat man sich da so rein manövriert dass man das mittels Unittests „beheben“ möchte, stimmt der Aufhänger wieder.
Hey, ja genau das war ja der Kern des Videos. Auch wenn viele das hier vermuten, ich habe "perse" nichts gegen Unit Tests, sondern nur dann wenn sie in diesen Situationen das Problem nicht lösen und stattdessen Mehraufwände erzeugen. Gruß David
Meine Erfahrung ist, dass man automatisch besseren Code schreibt wenn man Unitests hat. Und die unitests kommen natürlich nicht am Schluss, sondern spätestens nach der Hälfte der Programmierung, wenn man schon eine Idee hat, wie man die Aufgaben umsetzen will. Code nachträglich teststbar zu machen sind nur Schmerzen und ohne sehr große Not mache ich das nicht. Durch Unitests, die nicht nur Happy path Testing machen, finde ich den Großteil der Fehler, bevor sie meine Kunden finden. Und noch ein Vorteil: unit Tests sind die einzigen Code Dokumentation, die nie veraltet. Will ich wissen, wie sich eine Klasse in Grenzfällen verhält schau ich in die Unitests. Wie geht sie bei fehlenden Werten um? Exception oder Fallbackwerte? Nur als Beispiel.
In den Projekten in denen ich gearbeitet habe, hatte ich oft das Gefühl, dass Unit tests nur geschrieben werden, um eine Test Code Coverage zu erfüllen, die von einem corporate requirement vorgegeben wird. Ich habe Zweifel dass das sinnvoll ist :(
Sehr gutes Video! Stimme mit den meisten Punkten zu deiner Sichtweise mit Unit Tests überein. Dachte schon ich wäre einer der wenigen Entwickler auf diesem Planeten der Unit Tests kritisch sieht. Bin froh das ein Experte wie du da ähnlicher Meinung ist wie ich 🙂 Für manche Entwickler mögen Unit-Tests unabdingbar sein (kann ich selbst nicht so gut bewerten, da in den letzten 7 Unternehmen in denen ich gearbeitet habe Tests immer nur optional gehandhabt wurden), aber nur weil ein Stück Software eine hohe Ausfallsicherheit besitzt, heißt das nicht automatisch, dass die Wartung und Handhabung dadurch besser wird. Sowas entscheidet mehr eine vernünftige Struktur, ein gutes Regelwerk zur Handhabung von Sourcecode und die Ausbildung der jeweiligen Entwickler. Stimme da zu 100% zu.
Amen! Genau das wollte ich damit sagen und besonders das bei der ungeeigneten Struktur die Sachlage vollkommen anders ist und es mitunter eher gefährlich ist. Gruß David
Super Video. Wann sollte man anstelle von unit tests auf integrations bzw. end to end tests setzen? Nehmen wir mal an man bekommt keine vorgaben bzgl. der testabdeckung und befindet sich im microservice Umfeld - was wäre so das absolute Mindestmaß im Industrie Standard um die Qualität aufrecht zu erhalten ohne testfälle per Hand durch testen zu müssen?
Год назад+1
So - kurzes Video zu Ende geguckt - und Zustimmung: bei einem kaputten Projekt bringen UnitTests nichts.
Hey Steffen, bin froh das zu mindest bei einigen die Kernaussage rübergekommen ist, da muss ich wohl doch etwas mehr am Videoaufbau arbeiten :) Gruß David
"Meetings are terrible, so schedule another meeting right afterwards." (just kidding, I also operated with this workflow for a while - I prefer shorter and smaller stand-ups thouhg, and just blocking everyone's time for adhoc afterwards)
Hallo David, late to the party, so ist das, wenn man zwischendurch mal relativ frisch abonnierte Kanäle durchforstet. Trotzdem -- du scheinst eine falsche Vorstellung davon zu haben, wie man Tests schreibt. Tests, auch Unit Tests sollten möglichst gar nicht mit dem Code gekoppelt sein. Tests sollten ein Verhalten nachprüfen, also der Frage nachgehen, welche Ausgabe erwarte ich bei welcher Eingabe. Wenn also irgendwo eine Änderung gemacht wird, sollten da nicht ganz viele Tests fehlschlagen, es sei denn, die Funktionalität wird grundlegend geändert. Aber das dürfte bei den wenigsten Änderungen tatsächlich der Fall sein. Oder die Architektur ist eher schlecht, sodass viele Seiteneffekte durch die Änderung entstehen. Aber in diesem Fall haben die Tests ja ihre Aufgabe exakt erfüllt. Oder habe ich dich falsch verstanden?
Ich kenne die 1-2-4 Regel nicht. Ich kenne AAA Muster, aber das ist wohl nicht das selbe. Außerdem schreibe ich zuerst Tests, danach den Code. Bin aber kein C# Developer, also weiß nicht wie da getestet wird.
Hallo Heinrich, das AAA Pattern bezieht sich auf die Strukturierung von Tests, die 1-2-4 Regel bezieht sich auf die zu erwartenden Aufwände :) Gruß David
Hi David, ich finde man müsste deine Ansichten etwas differenzierter betrachten. Bei deinem angeführten Beispiel mag die These der Unit-Tests stimmen, hier ist aber auch die Ausgangslage nicht ideal. Die Software ist starr und unflexibel sowie vermutlich nicht ansatzweise genug modularisiert, um doch die eigentliche Stärke der Unit-Tests auszuspielen: Ich kann mich auf einzelne Komponenten oder Funktionen verlassen, die ich in meiner Anwendung dann nutzen kann, die Anwendung selbst als Ganzes sollte dann mittels anderer Testmethoden untersucht werden. Die eigentliche Stärke der Unit-Tests liegt bestimmt nicht im Legacy Code, sondern in Verbindung mit Test-Driven-Development in der Neuentwicklung. Hierbei macht sich der Entwickler doch schon vorher Gedanken über testbaren (aka guten?) Code und dessen Randbedingungen. Uni-Tests sind sicher kein Allheilmittel, gut durchgeführt und geplant sind sie allerdings in der Lage, einzelnen (kritischen) Komponenten eine bis zu sehr gute Stabilität zu gewährleisten und diese langfristig sicherzustellen
Hallo Tobias, leider muss ich bei der Menge der Kommentare hier einsehen, das der Aufbau des Videos nicht besonders gelungen ist. Genau das was Du sagst sollte der Punkt sein, im "normalen" Betrieb liebe ich Unit Tests aber das Problem ist, das wenn das Projekt bzw. das Design nicht in einem optimalen Zustand ist, dann bekommt man extreme Probleme. Das sollte die Kernaussage sein, leider nicht so gut rübergekommen. Gruß David
@@DavidTielke ja da muss ein Folgevideo her. die Aussagen so wie sie rüberkommen sind sehr gefährlich. Es hört sich nämlich bisschen zu sehr danach an, dass UT nichts bringen. Ich bin davon überzeugt, dass (egal welche Anwendung) 80-90% der entwicklung TDD gemacht werden können, und dass das auch schneller ist. WEIL in einer ordentlichen architektur 80-90% nicht einfach über GUI/IO zu testen sind. und automatisch eine modulare architektur mit pure functions, SOC, SRP, DRY, etc entsteht. zu oft sehe ich devs die mit stdout, console.log, etc. features rausfummeln die schlecht geschrieben sind, und danach "alibi tests" schreiben.
Ich finde den Videotitel etwas irreführend. Wir haben auch alten Code aus den 90ern "geerbt", bei dem Unit-Tests sinnlos wären, weil der Code dermaßen ineinander verbastelt ist, dass sich schlichtweg keine *sinnvollen* Unit-Tests schreiben ließen, selbst wenn man wollte. Die können wir praktisch nur über Integrations-Tests testen. Die Software macht die meisten Probleme, weil Änderungen/Erweiterungen so eine Art 4D-Mikado sind: Man zieht ein Mikado-Stäbchen aus dem Haufen am Wohnzimmertisch und in der Küche fällt ein Glas aus dem Regal ;-) ... refactoring ongoing ... Auf der anderen Seite muss ich aber sagen, dass jene Projekte, bei denen ich von Anfang an mit Unit-Tests gearbeitet habe, die problemlosesten sind. Sie lassen sich mit dem geringsten Aufwand warten und ergänzen. Da kann ich ohne Probleme Features dazubauen und ergänzen - wenn meine Unit-Tests nicht anschlagen, kann ich mir schon zu 90% sicher sein, dass auch die folgenden Integrationstest funktionieren werden. Wir haben aber ohnehin eine automatisierte, mehrstufige Teststrategie in der Firma (numerische Simulation): Unit-Tests, Commit-Tests, Nightly-Tests (die laufen einmal in der Nacht, weil die mehrere Stunden brauchen), Weekly-Test (die laufen Tage). und dann noch Long-Running - da kann ein einzelner Test auf einem Cluster schon mal mehrere Tage lang laufen.
Ich stehe Unit-Tests auch ambivalent gegenüber, aber dieser Argumentation kann ich nicht folgen. Das ist ungefähr so, als wäre es schlecht, einen Gesundheitscheck beim Arzt zu machen, und der Arzt dürfte kein Stetoskop benutzen und keine Labortests veranlassen. Unit-Tests sagen mir, ob eine Funktion so läuft wie erwartet. Wenn bei größerer Refaktorisierung die Tests erwartungsgemäß fehlschlagen, ist das kein Unterschied, ob ich das ignoriere oder sowieso keine Tests habe, es sei denn, die sind so fest in der Build Pipeline verankert, daß ein Deployment gar nicht mögich ist. Warum ich Unit-Tests nicht der Weisheit letzter Schluß finde, ist daß die Architektur um jeden Preis an die Testbarkeit angepaßt wird. Umgekehrt würde ein Schuh draus. Die Architektur muß die Anforderung der Softwarelösung abbilden. Die Tests müssen so gestaltet sein, daß sie die gegebene Architektur testen können. Das bieten Unit-Test-Frameworks meistens nicht. Sie müßten an jede Codestelle springen können und an beliebiger Stelle abbrechen. Ich muß testen können, ob die if-Bedingung korrekt funktioniert, ohne daß der Code im Block ausgeführt wird. Ich muß den Block testen können, ohne von der Bedingung anhängig zu sein.
Link nicht, nutze das schon seit Jahren - urspünglche Quelle ist (glaube ich) "The Art of Unit Testing", aber kann diese aus meinen Projekten bestätigen. Gruß David
@DavidTielke alles schön und gut, aber ich glaube nicht, dass viele unit tests brechen sollten, wenn ich ein feature ändere. dann sind das keine unittests. unit tests sollten isolierte einheiten testen. wenn das so ausstrahlt, dann ist was mit den unit tests faul. regressionstests, e2e tests und integrationstests brechen (in absteigender ordnung) viel öfter
Sehe ich anders. 1) jeder Entwickler testet. Oft am lebenden System, manchmal mit einem REPL Ansatz, aber niemand schreibt Code und probiert ihn nicht aus. Der Sprung von nem dreckigen Testbett hin zu einem formalen Test den man auch einchecken kann, ist nicht sooo riesig, und dafür wiederholbar. 2) das Argument mit der Aspirin ist schon gut, aber ich halte es schon für schwer (wenn auch nicht unmöglich), dass man Tests schreibt ohne etwas über besseren Code zu lernen. 3) Code lügt nicht. Habe noch nie ne korrekte Entwicklungsdoku gesehen, aber Tests machen verifizierbare Aussagen übers System.
Lustig, sehe es ganz anders. Klar, bist Du langsamer mit Unit-Tests, aber Unit-Tests waren nie als zeilenweise Abdeckung Deiner Klasse gedacht. Sondern zur Abdeckung Deiner Unit ... Zb des Moduls.
Ja was nu, lieber „langsam“ korrekten Code liefern oder „schnell“ Bugs liefern? Scheint mir ne ausgesprochen abgehobene und Managersicht ohne Praxisbezug zu sein.
Aber ernsthaft, natürlich bringt es nichts, für einen BBoM Unittests zu schreiben und Accessormethoden von Valuetypes werden durch andere Tests automatisch mitgetestet, weil es sinnlos ist, Valueobjects zu mocken. Aber alles, was Verhalten hat, profitiert durch Unittests. Und sollte es das nicht tun, dann ist es wohl entweder zu klein um eigenständig zu sein oder zu groß und tut zu viel. Ausnahmen sind interessant und selten. ;-)
Ich finde es ganz erfrischend, wenn die heilige Kuh mal ein wenig gegrillt wird. Ich hatte auch schon länger insgeheim auf das "Tod durch Unit Tests" gehofft. Kann man das nicht umbenennen in "Paralyse durch Unit Tests" und einen Disclaimer davor hängen? Ich durfte mal eine Test-Hölle kennenlernen, bestehend aus Unit-Tests, Integration-Tests und n2n-Tests. Meine spektakulärsten Werte waren: - Ein halber Tag Implementierung und vier Tage Tests angleichen. - Zwei Tage Implementierung und zehn Tage gegen die Test ankämpfen, die ich dann letztendlich beinahe unbrauchbar gemacht hätte. - - Ohne Hilfe eines alteingesessenen Insiders ging da nichts mehr. Wenn man am Legacy Code zugange war, ging flugs die Coverage runter. Das musste man dann beim zeitlich überlasteten Team Lead extra beantragen, damit der das durch die Pipeline winkt. Kein Spaß das. Und ganz offensichtlich aus tiefster Not geboren. Zu Haufe höchst kritischer Geschäftsvorgänge verteilt in einer schwer durchdringbaren Codebase. (Hohe Kopplung quer durch die Landschaft. Zu Haufe Gigabyte schwere MySQL-Tabellen die sich ganz weit waagerecht scrollen lassen. Also das was man so liebt. :-D ) -------------------------------------------------------------- Hat nicht Uncle Bob Martin die Legende in die Welt gesetzt, TDD hätte keinen zeitlichen Mehraufwand? Ich kriege davon ein flaues Gefühl im Magen. Ich hatte in meinem jetzigen Betrieb von einem Entscheider den Spruch "Das sollten wir in TDD manchen, weil das besseres Code Design erzwingt." Also Dependency Injection allein macht kein gutes Code Design. Oder? Und TDD um jeden Preis führt dazu, dass ggf. schlechtes Code Design betoniert wird. Ich hatte da einen Fall, wo ein fettes JSON als Testeingabe von einer 500-Zeilen-Methode verwurstet wurde. Zyklomatische Komplexität vom feinsten. OK, so was sind vermeintliche Unit Tests und in Wahrheit schlecht wartbare Integration Tests. Macht es auch nicht besser. Dann kommt gerne mal das das Wort von "mit TDD bin ich schneller". Tja, ist ja schön für dich, aber was ist mit mir? Betretene Stimmung nachdem ich im Zuge eines umfassenden Refactorings, der kaum einen Stein auf den anderen ließ, alle zugehörigen "Unit Tests" ersatzlos weggeworfen hatte.
Tests, die nur alteingesessene Entwickler lesen können??? Ich glaube, da ist was kräftig schief gelaufen. Gerade die Tests sollen leicht verständlich sein. Hilfreich ist dabei sind natürlich, SRP und Co. im Projekt zu benutzen. Kompliziert wird es ein wenig beim Mocken. Mir kommt es so vor, als bist Du nur Froh, dass David die Tests etwas schlechter macht, weil Du sie nicht magst. UnitTests sind Tests auf unterster Ebene und sind keine Integrationstests o.ä.. Unit Tests sollen Funktions gebunden sein und nicht über eine Gruppe von Funktionen. Genauso umgekehrt. Daher weiß ich nicht, wenn man eine Änderung in einer Methode macht, das man mehrere Tage an vielen UnitTests sitzen muss?
@@marcusreinicke genau, frei nach dem motto ah ich brauch keine tests, gugg ich mir später an was alles knallt, und oh jetzt muss ich aber vier Tage Tests angleichen. Klarer Fall von Ignoranz und dann braucht man sich auch nicht beschweren das man so lange Tests fixen muss :) Besser kleine Änderungen und iterativ laufen lassen.
> "Mir kommt es so vor, als bist Du nur Froh, dass David die Tests etwas schlechter macht, weil Du sie nicht magst. " Das muss ich in aller gebotenen Höflichkeit zurückweisen, auch wenn mir im realen Leben wegen meiner kritischen Haltung ein wenig der Ruf anhängt, dass ich "keine Tests mag". Ich mag nicht, wenn die Dinge aus dem Ruder geraten. Ich habe ja reale Fehlschläge aufgezählt und Du hast die ja in Deiner Antwort z.T. bestätigt. Ich habe generell was gegen "Religion". Damit meine ich: Nichts ist Kontext-unabhängig. Jedwede Technik, jedwede Vorgehensweise bedarf eines Kontextes, in dem sie funktionieren kann. Ist der Kontext nicht gegeben ist entweder der Kontext herzustellen oder Technik/Vorgehensweise wegzulassen. Wenn eine "TDD Religion" dazu führt, dass Entwickler mit der Auffassung "mit TDD liege ich immer richtig" bei einem 100%-Bottom-Up-Approach (~ "null Vorplanung") gegen eine externe Black Box coden und ein resultierender "Unit Test" eine 500-Zeilen Methode mit einem komplexen JSON als Eingabe testet, dann habe ich was dagegen. Dann gibt es Klärungsbedarf. Wenn ich kämpfen muss, damit ich meine injizierten Abhängigkeiten sinnvoll gemockt bekomme, dann ist das ein Zeichen, dass evtl. erst ein anderes Problem zu lösen ist. Oder die Sinnhaftigkeit von Unit Tests an der betreffenden Klasse ist zu hinterfragen. Selbstredend sollten die Testfälle "bis aufs letzte Bit" atomisiert sein. Sonst sind es keine Unit Tests. Ich nehme an, "SRP & Co." sind nicht nur hilfreich, sondern Voraussetzung. Bei meinem "Bericht aus der Hölle" kamen undurchsichtige Workflow-Logik mit undurchsichtigen n2n/Integration-Tests zusammen. Also schlecht mal schlecht multipliziert. Wäre übrigens durchaus dankbar für Empfehlungen für n2n/Integration-Test-Guides.
@@guidoerfen7944 Methoden mit 500 Zeilen? Ja gibt es zuhauf in alten Projekten. Aber Methoden mit 500 Zeilen kann man nicht sauber testen. In neueren Projekten sollten 500 Zeilen verpöhnt werden. Da läuft sonst was anderes ganz gehörig schief.
Hallo Guido, och als grillen empfinde ich es gar nicht, ich genieße die Diskussion hier sehr :) Aber es ist wieder das im letzten Kanalupdate angesprochene Thema, sobald hier etwas kritisiert wird was Entwickler lieben und schätzen werden die merkwürdigsten Dinge in meine Worte interpretiert - hier hatte ich das aber schon erwartet :) Das mit dem Titel ist leider immer ein sehr schmaler Grad, weil es dann einige wieder als Clickbait empfinden und andere meinen das im Video nicht das Thema behandelt wird, deshalb dachte ich das hier passt am besten. Gruß David
Hi David,
auch wenn es nicht häufig der Fall ist, bin ich da aber zu 90% einer anderen Meinung!
Das einzige, wo ich dir zustimme ist, dass es sich als kontraproduktiv erweist, wenn man UnitTests erst im Nachhinein schreibt. Das ist immer problematisch, da der Code teilw. noch nicht einmal testbar ist und man ihn aufbereiten muss, damit er testbar wird.
Aber eine pauschale Aussage dieser Art zu treffen, halte ich für Maga-Gefährlich! Stell dir mal vor, da kommt ein sehr junger Programmierer zu seinem Chef und sagt: "Der Thielke hat gesagt, man braucht keine UnitTests und langfristig kosten die 5x soviel Zeit". Ich kann mir nicht vorstellen, dass dann irgendjemand sagt: "Yolo, mach die trotzdem!".
Mal ein Beispiel aus der Praxis: wir hatten mal hier einen Monolithen ohne UnitTests etc. nach ca. 2 Jahren war der Code unwartbar und hatte mehr Bugs als Features. Dann haben wir die gleiche Funktionalität in eine Anwendung nach der CoCo-Architektur überführt und mit TDD kombiniert. Und siehe da, die Anwendung ist sehr stabil, hat kaum Bugs und unsere Tester zweifeln an sich selbst, weil die keine Bugs finden. Neue Features? Kein Problem, sind relativ schnell drin. Und wir sprechen hier von einer Anwendung mit 90k+ LoC! Diese Anwendung ohne UnitTests wäre reiner Selbstmord!
Und nein, ich stelle nicht die CoCo-Architektur über UnitTests. Das ist halt eine perfekte Ergänzung und wenn man beides zusammen einsetzt, wird es richtig cool.
Aus eigener Erfahrung kann ich auch sagen, dass ein Feature umso teurer wird, wenn keine UnitTests existieren.
LG
Sergej
Hey Sergej,
1. Meine Aussage war nicht pauschalisiert, ich habe differenziert gesagt das:
- Unit Tests sehr gut sind um komplexe Bereiche abzusichern
- Der Aufwand der Wartung häufig unterschätzt wird
- Unit Tests schädlich sind, wenn Sie eingesetzt werden um die erzeugten Probleme einer schlechten Architektur zu "verdecken"
2. Ich habe nicht gesagt das man keine Unit Tests braucht, sondern das man die Kosten (1+2+4) gegenüber dem Nutzen abwiegen muss und deshalb nur relevante Stellen testen sollte um dort die Funktion zu gewährleisten
3. Ich prognostiziere mal, das ihr TDD (wie Du selbst gesagt hast) nur punktuell eingesetzt habt. Die bessere Stabilität kommt meiner Vermutung nach von der sauberen Architektur (CoCo reduziert die Komplexität auf ein Mindestmaß, folglich werden weniger Fehler gemacht) und nicht zwangsläufig durch die Tests
4. Aus meiner Erfahrung versichere ich Dir, ein Feature wird umso teurer je schlechter die Architektur ist - mit Unit-Tests hat meiner Meinung nach nur begrenzt etwas zu tun.
Und in einem Punkt widerspreche ich Dir ganz klar: Eine ordentliche Architektur ist für die Stabilität immer wesentlich wichtiger als Tests!
Lg
David
David, natürlich ist eine ordentliche Architektur federführend und weniger Fehleranfällig. Keine störendere Redundanz, bessere Widerverwendbarkeit, etc.
Aber dennoch bleiben einzelnen Teile der Software über zum Testen.
Viele logische Fehler können im Vorfeld durch UnitTests (nicht immer) abgefangen werden, die vielleicht durch die weiteren Tests fallen würden.
Ich denke, das Gesamtpaket ist die Lösung.
Was ist wichtiger? Qualität, die jedes Audit besteht. OderSoftware, wo vielleicht ein Teil X ungewiss ist, obwohl die Architektur stimmt.
@@DavidTielke Gute Architektur kommt auch durch Testdriven development da man sich vorher gedanken machen muss was man eigentlich erreichen will. Welcher Leiderprobte Untermehmer hat dich bezahlt um dieses Video rauszuhauen? :D Ne im Ernst ich teile deine Meinung mit der 1-2-4 Regel (so hab ich das ehrlich auch noch nicht gesehen) aber es macht für mich sowohl zeit- als auch kostentechnisch einen grossen Unterschied ob ich die Zeit in einen automatisierten Test stecke oder dumm die Applikation (am besten noch im Produktivsystem) zu debuggen. Dann ist nämlich nicht nur meine Arbeitszeit ein Kostenfaktor sondern auch der nicht gemachte Umsatz im Onlineshop. Das nicht produktive Arbeiten mit einer Anwendung die Fehler enthält ist ebenso ein Kostenfaktor der langfristig auch mehr schadet und mehr Geld kostet. Zudem ist der psychische Druck auch nicht zu unterschätzen. Fehler die schnell gefunden werden müssen sind besser zu beheben wenn man die Anwendung noch nicht produktiv hat. Kranke Mitarbeiter sind auch ein Kostenfaktor :)
@@sebastianforster7992 Das ist einfach nur falsch. Kann ich aus der Praxis sagen. Architektur wächst nicht aus Test Driven Development. Sondern Architektur definiert die Schnittstellen und dann kann mit Test Driven Ansatz eine solche Schnittstelle implementiert werden.
Wir verwenden bei uns z.B. die Clean Architecture (Onion) mit all ihren Vorteilen. Die ist aber nicht aus der Testgetriebenen Entwicklung entstanden sondern das Konzept musste vorher durch entsprechende Projekte und Interfaces erstellt werden und danach konnten die einzelnen UseCases mit Testgetriebener Entwicklung umgesetzt werden.
@@pinguincoder du wirst mir sicher zustimmen, das es extrem schwer ist eine nicht getestete Komponente nachträglich mit Tests zu versorgen deutlich schwieriger ist als von vornherein mit den den Tests zu arbeiten. Testbarer Code ist immer viel leichter wieder verwendbar als nicht getesteter Code. Das ist meine 20 jährige Erfahrung. Und darum gehts am Ende um Zeit und Kosten zu sparen.
Wenn man bei einer Änderung vom Code viele Tests anpassen muss, sollte man überlegen, ob man SOLID begriffen hat..Tests sind such dazu da, um zu begreifen was man eigentlich programmiert
Eine gute Architektur ermöglicht es, Unit-Tests so zu schreiben, dass sie sich möglichst wenig überlappen und somit bei einer kleinen Code-Änderung auch nur wenige Tests angepasst werden müssen.
Durch Code-sharing zwischen Tests (DRY) kann der Umfang der nötigen Anpassungen minimiert werden.
arbeite seit gut 20 Jahren in diversen Sprachen mit Unittests. Und das Argument "erschweren Refactorings" habe ich bisher auffallend häufig von Leuten gehört, die selbst keine Erfahrung im Testsschreiben haben. Ich finde günstige, fehlerarme Refactorings werden gerade durch Unitests ermöglicht. Und viele meiner Kollegen, die wissen wie man testbaren Code schreibt, sind auch der Meinung.
Natürlich: du schreibst besser strukturierten Code, wenn du ihn zusammen mit Unittest entwickelst!
Also wir hatten das Maintenance Problem nicht. Wenn wir wirklich "große" Änderungen machen mussten, dann lag es daran, dass uns der fehlgeschlagene Test auf Problem durch einen Change hingewiesen haben. Hies also entweder die neue Businesslogik anpassen oder die Alte.
Bisher haben die Tests bei uns immer Seiteneffekte in anderen Komponenten aufgezeigt, die nur über einen Kompletttest aller Prozesse aufgefallen wären.
Wenn sie denn in dem gesamt Test auffallen, schlimmer wäre es, wenn sie erst Monate später beim Kunden auffallen und die Datenqualität dadurch leidet.
Hallo Andre,
interessant das du es "Maintainance Problem" nennst, weil viele haben es hier genau so verstanden wie Du und ich frage mich wie man das Video so verstehen konnte. Die Aufwände hat man immer, weil genau das wollen wir mit den Tests bezwecken, aber sie sind halt da. Das diese Aufwand sinn macht, gar keine Frage aber er ist eben da. Es ging vielmehr darum, dass wenn man es in den falschen Projekten anwendet, man in Teufels-Küche kommen kann. Das hier war keine verallgemeinerte Aussage über Unit Tests :)
Gruß David
@@DavidTielke Das die ganze auch Schief gehen kann, ist klar. Ich wollte einfach mal meine Erfahrung mitteilen.
Wie du auch schon in anderen Videos gesagt hast, man sollte sich überlegen/ wissen was man tut und nicht einfach drauf losen "programmieren".
Gute Unit-Tests zu schreiben ist eine eigene Kunst, die viel zu selten Beachtung findet. Du beschreibst hier genau die Tests, die ich anfangs voller Enthusiasmus selbst geschrieben habe: Man testet fast alles, 99% Coverage als Ziel, indem man jedes Detail bearbeitet, vor allem das Unwichtige.
Und am Ende testet man leider nicht das, was man eigentlich testen möchte, nämlich die Funktionalität des Features, sondern man testet, ob ein Knopf einen Methodenaufruf triggert (also das UI-Framework), oder ob der Aufruf von Methode X die Methoden Y und Z in dieser Reihenfolge aufruft (also Implementationsdetails), ob man in eine gewisse if-condition rein kommt, wenn man Daten ganz besonders formt (also den exakten Flow), ob in irgendeiner Liste, die ein Implementationsdetail ist, ein Wert vorhanden ist, den man vorher rein gesteckt hat, etc. (also interne Datenstrukturen).
Oft testet man, ob das Programm den exakten Fluss hat, den man sich ausgedacht hat. Und natürlich ändert sich der auch mit jeder Änderung der Funktionalität und schon ist man in der Falle, die du beschrieben hast.
Andere Tests testen nicht mal irgendwas, was rein oder raus geht, sondern die laufen einfach nur durch und sind immer grün. Warum? Weil man den unendlich großen Fehler begangen hat, dem Management die Test-Coverage zu zeigen und das plötzlich 60% oder mehr Test-Coverage fordert und dann die Devs jeden schmutzigen Trick nutzen, um die automatisch erstellte Statistik hoch zu bekommen. Man testet nicht, man triggert die Zähler von Cobertura, Codecov, usw.
Der Grund ist nicht, dass man Unit-Tests hat. Man testet die falsche Unit.
Was man eigentlich testen möchte ist, z.B. wenn ich eine Transaktion abschließe, dass eine Abbuchung vom Lager stattfindet und ggf. eine Mail getriggert wird und ich möchte z.B. dass in der Mail die Posten enthalten sind. Der Rest des Weges ist mir aber recht egal. Meine Unit sind nicht alle Methoden auf dem Weg dahin, sondern meine Unit ist der Geschäftsfall, das Feature, das Requirement.
Das erklärt vielleicht auch den zwischenzeitlichen Hype um "BDD" (Behavior Driven Development) als scheinbaren Kontrast zum "TDD (Test Driven Development). Dabei machen beide im Idealfall exakt das Gleiche.
Wenn man natürlich die Implementation einer besonderen Map testet, oder eine Methode, die eine Email-Adresse auf Gültigkeit prüft, dann sind Unit-tests auf dem Level von ein oder zwei Methoden oder einer Klasse und sehr isoliert und eigenständig also problemlos. Wenn ich aber die Business-Logik meines Programmes teste, dann ist die Einheit unter Test nicht das technische Detail der involvierten Objekte, sondern der Geschäftsfall. Das wird immer wieder falsch gemacht, weswegen dann Videos wie deines kommen, die Unit-Tests in einen Topf werfen, in den sie nicht rein gehören.
Jetzt kann man natürlich sagen: "Das ist ein Integrationstest, kein Unit-Test" und da muss ich widersprechen: Ein Integrationstest ist es nur, wenn ich die Integration mehrerer Systeme teste, nicht, wenn ich z.B. teste, ob wenn ich eine High-Level-Methode triggere, dort, wo ein Call in ein Email-System raus gehen sollte, auch ein solcher aufschlägt. Ich platziere meinen Test an der Boundary meines Systems, ein Integrationstest wird es erst, wenn die Boundary zwei Systeme überspannt, wenn ich also teste, ob etwas, was in System 1 geschieht, von System 2 verarbeitet wird.
Meine Mocks sind an den Schnittstellen und die sollte ich vorrangig testen. Und wenn ich die entsprechend gut teste, dann komme ich ebenfalls auf eine hohe Coverage, nur eben versperre ich mir nicht den Weg zur Weiterentwicklung indem ich unnötige Details teste.
Was Tests aber schonungslos offenlegen, besonders während eines Refactorings oder einer Änderung, ist wenn man zu lange Abhängigkeitsketten hat, weil man zum Beispiel interne Datenstrukturen leakt. Etwas, wie: "getBlaManager().getFoo().getBar().add(junk)" hat wohl schon jeder gesehen, das ist ein Klassiker, wo "foo" und "bar" Details sind, die man nicht sehen will, weder im produktiven Code, noch im Test. Hierzu sei auch gerne das "Law of Demeter" genannt, welches man vielleicht nicht allzu streng auslegen sollte, aber immer im Hinterkopf behalten muss, wenn man wartbare Software schreiben will. Das Law of Demeter hilft auch, Test-Units zu bekommen, die sich weniger mit den Interna beschäftigen, sondern mehr mit der API, mit der Domäne.
Und leider, das ist auch oft der Fall, gibt es immer noch Antipatterns, wie das Singleton, die das Testen wirklich unnötig schwer machen.
Wenn ich ein Objekt habe, welches Bestellungen entgegen nimmt, und eines, welches aus einer Bestellung eine Email macht und eines, welches eine Email verschickt, dann möchte ich die doch austauschen können, gerade um mich nicht mit den Details einer Implementation herum schlagen zu müssen, sondern damit, ob der Geschäftsfall so abläuft, wie vorgegeben.
Tatsächlich wird man genau dann mit Tests schneller, wenn die sich nicht in Details verlieren. Ich kann mit einer wirklich guten Testsuite sehr hart refactoren mit wenig Sorge, dass etwas unerwartet kaputt geht. Mit einer schlechten Test-Suite refactore ich mehr Tests als Code.
Du redest vom Aspirin-Problem: Dein Problem, die schlechte Entwicklungsgeschwindigkeit wegen Tests sind ein Symptom und dein Aspirin ist: Tests wegschmeißen und auf wenige Bereiche, die hoch kritischen zu beschränken. Damit öffnest du aber haufenweise Lücken, die mit manuellen Tests und langsamen Integrationstests gefüllt werden, oder noch schlimmer Tests mit Point+Klick-Automation (Selenium. etc), die chronisch brüchig sind.
Die Ursache ist aber: Schlechte Wahl der Test-Units, also mangelnde Ausbildung der Programmierer.
Habe genau die gleichen Erfahrungen gemacht. Mocks die testen ob Funktionen aufgerufen werden verwende ich gar nicht mehr. Habe gute Erfahrung mit fakes gemacht, um Zugriffe aufs Filesystem, Registrierung etc. weg zu kriegen.
Finde die Begriffe unit test und Integration test nicht nützlich. Würde eher von low und high Level tests reden, oder von kleinen, mittleren und großen tests wie sie es bei Google machen.
An der Stelle möchte ich noch auf dieses Video hinweisen:
"TDD, Where Did It All Go Wrong (Ian Cooper)"
Leider wird dieser Hinweis immer gelöscht, wenn ich den RUclips-link poste, also selber suchen.
Danke, danke, danke!
Genau das!
Was aus meiner Sicht zum Beispiel auch müßig ist, ist zu testen falls die Datenbank nicht antwortet. Ich sage immer, dass man sehr schnell merkt wenn der Datenbank Server weg ist, das muss ich nicht testen.
Deswegen sind auch 95% Coverage Blödsinn.
Mocks sind nur dafür da, mein System von Systemen zu entkoppeln, die nicht in meiner Verantwortung sind. Der DB Server ist in meiner Verantwortung, das SAP System aber nicht. Meine Tests müssen laufen, auch wenn die Kollegen Wartungsarbeiten haben.
@@acboesefrau7729 genau das meine ich, wenn ich davon rede die Mocks an den boundaries zu platzieren. Schön zu lesen, dass andere es genau so sehen.
Ich finde es übertrieben zu sagen dass die Unittests mehr Schaden als Nutzen anrichten. Ich gebe zu, dass es Fälle gibt wo Tests zu Problemen führen können, wenn man sich nicht sicher ist was man genau testen will. Oder in einer Experimentellen Phase steckt und man ein Outcome sich erstmal erarbeiten muss. Aber, dass diese einen Schaden anrichten, konnte ich bisher nicht feststellen.
Auch, dass die Entwicklung schneller gehen soll mit den Tests, habe ich nie gehört. Eher geht es ja darum, dass man mit den Tests einen Fehler schneller nachvollziehen kann. Es kommt natürlich auf die Architektur drauf an. Aber es gab schon viele Fälle wo ich ein Fehler gemeldet bekommen habe, dann habe ich die Tests dazu geschrieben die diesen Fehler nachstellen und konnte es dann beheben. War oft der Fall wenn man mit externen APIs arbeitet wo sich auch mal der Response geändert hat.
Klar 100% TestCoverage sagt nicht darüber aus dass die Software bugfrei ist. Aber es schadet bestimmt nicht wenn ich mir die Mühe gebe und wenigstens 70% Code Coverage habe.
Die Tests haben halt das Problem, dass diese Fehler schon vorher unterbinden. Es ist schwierig zu messen wie unwirtschaftlich eine Software wäre ohne den Tests. Somit kann man auch schlecht sagen dass Tests nur unnötig Geld/Zeit kosten. Ich als Entwickler kann aber besser Schlafen wenn ich weiß dass 70% meines Codes mit wenigen Klicks geprüft werden.
Trotzdem finde ich das Video gut weil man über etwas diskutieren kann ;)
Viele Grüße
Hey,
Die Aussage, das die Entwicklung schneller gehen soll mit UT, habe ich schon etliche Male gehört, wie im Video bereits gesagt meist weil die Entwickler glauben so die Vorgesetzten davon zu überzeugen.
Was Du mit dem Nachstellen der Fehler beschreibst, ist ja ein komplett anderer Ansatz als das was ich hier beschrieben habe. Dort nutzt Du die Unit-Tests ja um die Anwensenheit des Fehlers zu zeigen und anschließend den Fix zu verifizieren. Absolut OK!
Da ist meine Kernaussage nicht richtig rübergekommen: Ich halte Tests in den richtigen Situationen für super. Solange ich es einsetze um Funktionen zu verifizieren ist alles in Ordnung, sobald ich sie aber nutze um die Menge der Fehler in der Software in den Griff zu bekommen, wird es definitiv problematisch, weil ich damit das eigentliche Problem nicht löse sondern nur unterdrücke.
Gruß David
Ah ok David, ja das stimmt.
UTs benutzen um Fehler oder Misstände zu vertuschen!? Geht das?
Das ist nicht deren Aufgabe.
Auch die Software über UTs zu debuggen, ist in manchen Fällen fragwürdig. Dafür sind UTs nicht gedacht.
@@DavidTielke die Schnelligkeit kommt durch bessere Architektur weil man Sachen wiederverwenden kann die man vorher ausreichend getestet hat :) Ein über die Jahre falsch entwickeltes, abseits des gängigen Software Handwerkszeug Produkt wird man nicht schnell auf Vordermann bringen können. Es hilft aber langfristig eben keine neuen Fehler einzubauen und man ist sicherer bei kleinen und auch grossen Änderungen. Auch hier ist die Wiederverwendbarkeit entscheidend.
Mir sparen Unittest jede Menge manuelles Testen. Was ich hasse. Und was niemand bei jeder Änderung für alle Funktionen machen will.
Natürlich testet man manuell bevor man es an die QAnoder den Kunden übergibt. Aber ich habe zu dem Zeitpunkt halt nicht schon 25 ,Al dasselbe Formular ausgefüllt.
"Wir implementieren Tests, um funktionale Sicherheit zu bekommen." - das ist mMn zu kurz gesprungen. Ich implementiere Tests, damit ich zukünftige Änderungen mit der Zuversicht durchführen kann, dass bereits umgesetzte Funktionalität weiterhin - ehm - funktioniert. Und wie schafft man das? Indem Tests jetzt(!) darin helfen das Design zu verbessern.
Wenn ich eins durch Tests gelernt habe, ist's, dass ich ohne (große) Angst vor dem Kaputtmachen von Funktionalität verschiedene Herangehensweisen an die Lösung ausprobieren kann. Das verbessert das Design enorm. Das macht es möglich, weitherhin Funktionalität zum Kunden zu bringen. Auch bei älteren Projekten.
Wenn man feststellt, dass durch neue Funktionalität viele alte Tests angepasst werden müssen, muss man sich seine Tests mal genauer anschauen. Vielleicht wird das Falsche getestet - Als Stichwort: "Zustand statt Verhalten"
TDD beats FDD (Fear Driven Design) anytime!
Hey Steffen,
funktionssicherheit bedeutet auch, das die Funktion bei Erweiterungen abgesichert ist - von daher: mit der Aussage gehe ich mit :)
Gruß David
Volle Zustimmung! Musste auch schon in einigen gescheiterten Projekten diskutieren, warum Tests uns grade nicht weiterhelfen. Nächstes mal werde ich deine Kopfschmerzmetapher anbringen, die ich sehr passend finde. Danke für deine Erklärung!
Hallo David,
Danke für deine Sichtweise!
Ich würde in deinem genannten Beispiel jedoch andere Ursachen folgern.
Es wurde ein System entwickelt, welches mit zunehmender Entwicklungszeit sehr viele/immer mehr Bugs verursacht hat.
Nun hat der Entwicklungsleiter darauf reagiert und festgelegt, dass für bereits bestehenden, ungetesteten Code Unit-Tests geschrieben werden sollen. Und dennoch hat dies kaum dazu geführt, dass in der weiteren Entwicklung weniger zusätzliche Bugs verursacht wurden.
Liegt die eigentliche Ursache evtl. darin, dass mit zunehmender Entwicklungszeit immer mehr technische Schulden aufgebaut wurden?
Und man die korrekte Zeitpunkte für Refactorings verpasst hat (sowohl für Software Design als auch Software Architektur)?
Ich nehme an, dass in dem Projekt von Anfang an kein automatisierte Testkonzept/Testpyramide vorhanden war/ist.
Sonst hätte es auch Unit-Tests gegeben.
Unit-Tests alleine können sicherlich nicht dafür sorgen, dass die Funktionalität/Erweiterbarkeit sichergestellt ist.
Schon gar nicht, wenn man Tests für Code schreibt, der von anderen Entwicklern vor langer Zeit geschrieben wurde.
Da entstehen keine qualitativ hochwertigen Unit-Tests.
Schon gar nicht, wenn der initiale Code "nicht testbar" geschrieben wurde.
Am Produktiv-Code will man dann wenig ändern, da das System ja an sich fehleranfällig ist.
Und dann werden halt Unit-Tests mit 10+ Mocks geschrieben, wo im Grunde e nicht wirklich etwas abgetestet wird.
Da helfen Unit-Tests dann natürlich nicht weiter.
Das liegt aber nicht an den Unit-Tests an sich, sondern, dass die Tests minderwertig geschrieben waren.
Aber mit einer vernünftigen Teststrategie haben qualitativ hochwertigen Unit-Tests (damit meine ich, dass man Tests nicht nur wegen der Coverage schreibt) ihre Berechtigung. Auch wenn sie nur trivialen Code abtesten.
Hallo Johannes,
sehr gerne!
Versteh das nicht falsch, hast Du dir das Video wirklich angeschaut? Ich meine die Frage ernst, weil ich versuche (mal wieder) einige der Kommentare hier nachzuvollziehen. Ja, natürlich lag das an den technischen Schulden. Genau das habe ich doch gesagt, das diese Probleme nicht mit UT gelöst werden können sondern man zuerst die Ursache (Architektur, also technische Schulden) beheben sollte.
Auch für den Rest den du geschrieben hast, bin vollkommen bei Dir. Aber nicht anderes habe ich doch in dem Video gesagt?!?
Gruß David
@@DavidTielkeich denke das Problem ist, dass du in dem Video einen speziellen Fall nennst,indem Unittest tatsächlich der falsche Lösungsansatz waren.
Besser wäre es in Salamitaktik Bereiche aus dem Monolithen rauszulösen, neu zu schreiben, diesmal gleich mit Tests und so nach und nach den Monolithen klein zu klopfen.
Aber ich denke viele Entwickler und Chefs nehmen aus deinem Video mit: Unittests sind Zeitverschwendung.
Das freut EntwicklerInnen, die keine Tests schreiben mögen, weil dies korrekt erwähnt gefühlt viel Zeit braucht. Da gibt man dem Kunden lieber Bananensoftware. Die Chefs sind glücklich, weil die Deadline gehalten wurde, der Entwickler kam wieder mal ohne Tests durch und dann entsteht über die Jahre schrottige Software.
Da bin ich ebenfalls anderer Meinung. Bei "einer" Änderung sollten niemals "ganz ganz viele" Tests fehlschlagen. Das klingt dann eher nach zu komplexer Logik.
Gerade, weil ich immer die Unittests im Hinterkopf habe, hat sich auch die Art geändert, wie ich "entwickle". Unterbewusst achte ich bei jedem einzelnen Schritt auf die testbarkeit (Kein TDD). Das hat in den letzten Jahren für messbar höhere Qualität gesorgt. Aber sicherlich auch von der Branche abhängig.
Das kommt immer darauf an, welche Architektur Du verwendest und welche Grad an Qualität Du in der Anwendung hast. Wenn Du/Ihr sehr stark im Software Design seid, mag der Effekt nicht so stark sein, vorhanden ist er definitiv auch bei Euch, da bin ich mir sehr sicher, sonst hättet Ihr eine Kopplung von 0 und das ist unrealistisch. Wenn Du aber ein Team aus mehreren Entwickler hast, ist es ein höllischer Aufwand genau diesen Status mit allen Entwicklern aufrecht zu erhalten.
Gruß David
Absolut. Ich sehe das ganze als Hassliebe bzw. notwendiges Übel. Sicherlich hat das einen moderat negativen Einfluss auf die Performance des Teams, aber das ist den Verantwortlichen wohl bewusst.
Den Verantwortlichen ist oftmals der Mehraufwand für das Schreiben der Tests bewusst, den Faktor der Wartung/Erweiterung ist leider nur wenigen Bekannt.
Gruß David
Ja da stimme ich dir zu. Das hier angesprochene Problem ist das "Fragile Test Problem" und es gibt genug Methodiken um dem beizukommen und eine Testsuite zu bauen, die eben nicht bei kleinsten Änderungen auseinander bricht.
Ist doch prima, dass dir die vielen fehlschlagenden Tests anzeigen, wo die Anforderungen nicht mehr erfüllt sind und welchen Impact die "kleine" Änderung tatsächlich hat. Unit Tests sind dein Sicherheitsnetz beim täglichen Refactoring und nehmen dir die Angst auch unbekannten Code anzufassen und zu verbessern.
Wann wird denn eine Software für Produktion freigegeben? Wenn alle Tests durchlaufen - die Tests sind praktisch die Requirements.
Moin, zuerst muss man mal differenzieren, was eigentlich mit Unittest gemeint ist. Unter "Unit", also einer Einheit, versteht so ziemlich jeder was anderes (nah meiner Erfahrung).
Wenn man den klassischen Unittest als Test einer Methode sieht, die alles andere durch mocking services simuliert, dann gebe ich Dir zu 100% recht, die sind meiner Erfahrung nach zu 99% sinnfrei.
Viel wichtiger ist das Zusammenspiel der Methoden und Komponenten, ich bin daher ein großer Freund von Integrationstests. Also von der UI oder WebAPI kommend bis zur Datenbank. Ja, das ist Aufwand, aber wenn man Umstrukturierungen vornimmt, müssen die Tests weiterhin laufen.
Und gerade bei länger laufenden Anwendungen, wo der Ansprechpartner beim Kunden wechselt, die Entwickler ausgetauscht werden oder auch nur das Framework von Core 3.1 auf 6.0 migriert wird, helfend diese Integrationstests enorm.
Der Meinung bin ich auch. Und meist schreibt man sich eh eine Art Integrationstest, um den eigenen Kram schon mal in Betrieb zu nehmen. Wenn man das gleich "ordentlich" und automatisierbar aufsetzt ist mit wenig Zusatzaufwand viel gewonnen.
Unittests dokumentieren den Vertrag einer isolierten Unit (und setzen ihn durch). Das kann ein IT so nicht leisten. Natürlich darf man die Unit etwas größer schneiden, als record(String, String).
Danke David, meine Seele ist etwas leichter geworden...;)
Hatte als technische Leitung irgendwann die Schnautze voll von der ganzen Test-Wartung. Is ja nicht nur so, dass das den Prozess verlangsamt, sondern dieser träge Balast auch immer wahnsinnig viel Kreativität der Entwickler kostet.
Hatte mir bis dato immer nen schlechtes Gewissen einreden lassen, irgendwann mal den Großteil unserer Tests einfach in die Tonne geworfen zu haben. Gut zu hören, dass das wenn auch intuitiv getroffen, wahrscheinlich die richtige Entscheidung war...
nein. einfach nein.
architektur und entwickler hätten gefixed werden müssen.
die tests löschen um die failing tests loszuwerden ist wie bei problemen zur flasche zu greifen.
@@devbert1880 schau dir das Video noch mal an. Es geht nicht um Tests die failen, weil der Code Fehler enthält. Es geht darum, dass Code sich ändert und dadurch bei jeder Kleinigkeit die Tests selber fehlerhaft werden. Der hierdurch erzeugte Mehraufwand muss gerechtfertigt werden, statt mit religiösem Eifer 100% Testabdeckung zu predigen.
@@yannicwelle4021das liegt aber am schlechten Design, nicht an den Tests.
Wenn du über schlechte Software Tests drüber legst, dann hast du den Fall.
Wenn deine Klassen nicht viele Abhängigkeiten haben, dann sind auch die Anpassungen bei Codeänderungen üblicherweise nicht groß.
@@acboesefrau7729 ich kann nur wieder ermutigen das Video noch mal zu schauen. Das hängt weder 1dimensional an Code noch Architektur, sondern schlicht damit, dass Unit Tests extrem oft nachjustiert werden müssen. Zumindest wenn man agil auf ein bewegliches Ziel zuarbeitet...
Du sprichst mir aus der Seele... eine Story - zwei Wochen, 2/3 Tage funktionales coden und den Rest Unit Tests updaten und damit die Runden drehen...
Guter Kanal. Viele wertvolle Kommentare von echten Entwicklern. Abonniert!
Vielen Dank!
Hallo,
also diese Sichtweise empfinde ich nun als mehr als schwierig. Für mich bringen UnitTests ganz klar Vorteile:
- Festklopfen der Logik: Man stelle sich eine Filter-View vor, die nach Anpassen mehrere Optionen eine URL erzeugt um damit neue Datensätze abzurufen. Dazu gibt es einen URL-Builder, der aus der gegebenen Menge der Parameter/Optionen eine korrekt formatierte URL erzeugen muss
- Testen von Logik ohne die App zu starten. Man nehme hier den angesprochen URL-Builder bzw. den dazugehörigen Filter. Man müsste jedes Mal die App starten, ggf. auf irgendeine View navigieren und zig Parameter einstellen und dann im Debugger schauen ob das richtige Verhalten zu beobachten ist
Das soll mal ein einfaches Beispiel sein das zeigt, dass recht häufig sogar Zeit gespart wird, da der Testaufwand während der Implementierung viel geringer wird. Ich implementiere nicht selten komplette Feature ohne die dazugehörige App überhaupt gestartet zu haben.
Leider muss ich sagen, dass der angesprochene Nachteil - nämlich die vielen roten Tests - mir die Haare zu Berge steigen lassen. Wenn ich Code ändere - und seien es nur 3 Zeilen - und ich habe eine Menge Tests die auf einmal fehlschlagen... ja was bedeutet das denn?
Da der Code kompiliert (sonst würden die Tests gar nicht laufen), wäre das Produkt letztlich so dann auch ausgeliefert worden oder wenigestens in den Test gegangen.
Das heißt doch, dass ich unmengen Fehler produziert habe und sich viele Stellen eben nicht mehr so verhalten wie vorher. Na da sollte ich in dem Moment doch dankbar um jeden Test sein den ich habe und nicht die Arbeit verteufeln.
Ich demontiere doch auch nicht den Feuermelder in der Küche, weil mich das gepiepse nervt.
Etwas anderes ist es, wenn man völlig sinnbefreite Test schreibt. Ja man kann durchaus übelst komplizierte Tests zusammenschrauben die sehr schwer in der Wartung sind. Das ist dann aber eher ein Problem, dass man die Einheiten ggf. nicht klein genug geschnitten hat.
Tests im Nachhinein schreiben kann man sich oft schenken, aber in Form von TDD würde ich niemals drauf verzichten wollen.
Ich sehe es hier auch wie mein Vorredner Sergej: mir wird hier sehr stark pauschalisiert, dass UnitTests verzichtbar sind. Und auch sehe ich es so, dass UnitTests durch TDD einen Teil der Architektur mitbestimmen. Denn um testbar zu sein, muss ich bestimmte Entscheidungen in der Architektur treffen, die ich ansonsten ggf. nicht treffen würde (min. lose Kopplung).
Hallo Klaus,
das mit dem Feuermelder ist ein super Beispiel: genau das meinte ich ja. Diesen Effekt will man ja erzielen. Aber wir müssen uns nicht alle vormachen, das Unit Tests uns schneller machen und in jeder Projektsituation sinn machen. Ich kenne zahlreiche Projekte wo genau diese Denkweise zum Scheitern des Projektes geführt hat. Es geht hier nicht darum, dass ich Unit Tests nicht mag, weil sie die Wartbarkeit kaputt machen. Es geht darum, dass mit der falsche Einsatz und die falschen Erwartungen dabei gegen den Strich gehen.
Gruß David
Wir haben damals mit nem alten FatClient mit backend JunitTests und MockTests gehabt. Dann haben wir mit UI Tests angefangen und gemerkt, dass diese die einzigen Tests waren, die Fehler aufgedeckt haben. Seit dem schreiben wir nur noch UI Tests, trotz längerer Laufzeit. Als wir den FatClient dann durch einen WebClient abgelöst haben, haben wir direkt mit UI Tests begonnen unf wir hatten noch nie eine so hoche Stabilität. Klar, die Tests müssen auch gewartet werden und die durchlaufzeit ist selbst bei parallelen tests mit der kompletten build pipeline und aufsetzen der testsysteme bei etwa 7Std, aber das läuft im Jenkkns und alles ist automatisiert. Wir lieben es 👍
Im Frontend stimme ich dir zu. Da konfiguriert man häufig die Testumgebung mit. Eine kleine Änderung zerstört die Testumgebung und damit auch die Unittest. Im Java Bereich im Backend muss man allerdings nicht viel konfigurieren. Man kann sofort mit den Test beginnen. Wenn ich weiß, dass ich auch Tests schreiben muss, hat das einen Einfluss darauf wie überhaupt die Funktionen geschrieben werden müssen. Sie sind lesbar und wartbar. Aber wir haben wir auch aktuell, dass die Projektstruktur einfach zu komplex geworden ist. Auch Unittest würden hier nichts mehr bringen
Ja. Ja,ja und ja!
Ich bin Backend-Entwicklerin und möchte nicht mehr ohne Tests coden. Die zeigen dir auch gleich, wo du beim Design in die falsche Richtung gehst.
Hallo David,
vielen Dank für das tolle Video. Ich sehe es ähnlich, bei vielen feingranularen Unit Tests zementiert man das aktuelle Softwaredesign und erhöht den Aufwand für spätere Änderungen.
Die 1-2-4 Regel fand ich ein tolles Bild, das ich noch nie gehört habe. Hast du dazu irgend eine Quelle? Ich denke das ist ein gutes Bild um genau die langfristigen Auswirkungen insbes. von unnötigen Erweiterungen, die wenig Mehrwert liegen zu zeigen.
Hallo David. Super Erklärung. Meine Meinung: Ja und nein. Ich baue immer mehr auf Tests auf und ja... Tests brauchen verdammt viel Zeit ABER die Fehlerquote und die "ah hab ich nicht bedacht"-Quote reduziert sich dadurch emens! Das ist ein super gefühl wenn man etwas entwickelt, es "anschließt" an die anderen Komponenten und es einfach nur geht.
Außerdem bin ich überhaupt kein Fan von einfach so mal los drauf testen. Tests gehören nur dort hin wo man die Funktionalität von außen benutzt. Sozusagen auf Modulinterfaces und auf wichtige Algorithmen. Wenn ich mich nun auch noch an die Regel halte, dass ich keinen Sinn einer aufrufenden Funktionsschnittstelle verändern darf sondern nur eine Neue machen darf, dürfen sich bei Änderungen auch keine Tests ändern!
Allerdings muss ich sagen, dass ich noch sehr wenig Erfahrung habe und ich daher nur Mutmaßungen treffen kann weil ich einfach noch zu wenig Szenarien miterlebt habe. Somit noch nicht weise genug bin.
Hallo Thomas,
die von Dir angeführten Punkte sind unbestritten. Aber ich finde es schlichtweg falsch da von Zeitersparnissen zu reden, denn dafür sind Unit Tests nun einfach nicht da.
Gruß David
Interessant wo kommt diese 124 Regel her? Ist die verifiziert?
Was für Tests machst du stattdessen System Tests? Wie verhält sich das mit dem Aufwand zu den unit Test?
Muss leider radikal widersprechen. Ohne Unittests wären Änderungen an vielen Stellen gar nicht möglich, ohne reihenweise Bugs einzuführen. Vermeidet viele Probleme und spart enorm Zeit im Nachgang.
Hallo David, es ist schon eine Sichtweise.
Ja, Du hast vollkommen recht, UnitTests erhöhen den Aufwand, und es ist falsch, dass wir durch UnitTests schneller werden.
Da bin ich vollkommen bei Dir.
Nur denke ich, das UnitTests, für eine wesentlich höhere Qualität der Software stehen.
Ich denke, dass Du hier ein wenig zu kurz das Thema angehst.
Es ist doch nur ein verschieben von Aufwänden, denn getestet werden muss immer.
Und es wird doch für die Tester einfacher, wenn von vorn herein die meisten Fehler schon rausgefiltert wurden.
Also wird der Aufwand der Tester reduziert.
Zusätzlich werden diese Tests noch dokumentiert.
Es ist ein zweischneidiges Schwert.
Viel schlimmer mit TDD, denn diese Art kostet noch mehr Zeit und damit Geld.
Aber es ist noch sicherer.
Kommt auf die Anforderung an.
Ja, Du hast recht, dass die Unit Tests in Folge von Änderungen, schief laufen können, aber genau das ist doch deren Aufgabe.
Im Aufbau von Unittests habe ich Fälle überprüft und Fehler gefunden, die ich im normalen Flow nicht gesehen, bzw. nicht dran gedacht habe.
Daher sehe ich UnitTests ein unverzichtbares Werkzeug für qualitative Softwareentwicklung.
Und wir wollen doch qualitative Software erstellen.
Hallo Marcus,
- Natürlich sorgen die UT für eine höhere Qualität
- Ja, absolut es ist ein verschieben der Aufwände - ohne Frage. Ob die Aufwände nicht eher durch einen günstigeren Tester erledigt werden können, steht nochmal auf einem anderen Blatt - aber das war niemals die Aussage von mir.
- Ja Test gehen bei Änderungen schief - vollkommen klar und das dann Aufwände entstehen und das gewollt ist, ist auch unbestritten aber die Aussage war ja, wenn beispielsweise die Architektur kaputt ist, löst ihr damit nicht das Problem sondern kaschiert es nur und die Zusatzaufwände bei der Wartung machen euch irgendwann platt.
Rückwirkend betrachtet kommt das Video für sehr viele hier leider falsch rüber :)
Gruß David
@@DavidTielke hallo David,
ja, ich habe auch etwas gebraucht dass zu merken, bzw. zu erkennen, was Du gemeint hast.
👍😏🖖🖖
Ich habe da eine andere Meinung zu. Wenn Testing falsch gemacht wird, dann kommt es zu diesen Problemen. Während der Entwicklung schreibe ich Unittests um testgetrieben bzw. Test First sicherzustellen. Nachdem ich dann einen Integrationstest geschrieben habe bzw einen Akzeptanztest dann kann ich die Unittests, die wie ein Baugerüst eingesetzt werden (sog. Scaffholding Tests) nach dem "Bau" wieder zurückbauen und der Integrationstest verbleibt um die Funktionalität abzusichern.
Für bestimmte Kernbereiche der Businesslogic (komplexe Berechnungen etc.) lohnt es sich die Unittests zu behalten. So mache ich das jetzt seit Jahren und kann dadurch das 1, 2, 4 Prinzip vermeiden
Hallo Nicolai,
genau das war der punkt, das es zu den Problemen kommt, wenn die Unit Tests in der falschen Situation eingesetzt werden. Ich habe nie die Sinnhaftigkeit angezweifelt, aber wir schrieben sie um Funktionssicherheit zu bekommen, nicht um schneller zu werden und wenn es bereits Probleme gibt (falsche Architektur usw.) ist es mehr gefährlich als förderlich zu testen.
Gruß David
Was ich immer gerne unit teste sind wirklich core components. E.G eine implementation von einer hashmap.
oder auch das networking protocol um sicherzugehen das die compatibility immer gegeben ist
danke für deinen Standpunkt, ich bin aber anderer Meinung. Ich habe bei weitem nicht deine Erfahrung in der Branche aber Ich wollte trotzdem mal diese Diskussion "zwischenwerfen". Du sprichst ab ca. 3:00 von dem 1-2-4 Prinzip und das der 4-fache Aufwand der ursprünglichen Realisierung einer Funktionalität dann später für die Wartung "drauf geht". Als Beispiel sagst du, dass durch viele unit Tests die _Erweiterung_ der Software problematisch wird, weil man dann manchmal viele Tests fixen muss. Und genau in diesem Punkt bin ich anderer Meinung. Wenn man seine Software erweitert, warum muss man dann unit tests zu bereits implementierter Funktionalität fixen? Im nächsten Satz sagst du dann, dass strukturelle Änderungen eben das fixen von unit Tests zur Folge haben. Ja, da stimme ich zu, aber, dann sind ja nicht unit tests die Verursacher des Mehraufwandes, sondern ein schlechter Klassenentwurf, mangelnde oder ungenaue Anforderungen oder schlicht weg, dass sich Leute nicht an best practices, patterns halten und die Software von vorne rein schon zu eng/stark gekoppelt ist.
Ich denke du hast in deinem Video ganz viele valide Punkte aufgezeigt, aber bist dann meiner Meinung nach zum Falschen Schluss gekommen, nämlich das unit Tests im Nachhinnein Mehraufwand verursachen, nur, weil man unit Tests benutzt.
Am Ende des Videos gehst du nämlich genau auf diese Punkte ein. Ich finde nur den anfänglichen Teil und den Titel vielleicht ein wenig irreführend. Unit Tests dann, wie von dir in der Mitte beschrieben, als "band aid" Fix für ein viel größeres Problem zu benutzen ist quasi der letzte Nagel im Sarg. Und ich glaube darauf wolltest du wirklich hinaus.
Ich glaube man muss dazu erwähnen, dass man als Entwickler lernen muss wie man gute Tests schreibt. Ein Unternehmen besteht aber in der Regel nicht nur aus Senior Devs und ja viele Fehler führen auf schlecht definierte Anforderung, Architektur oder auch Tests die zu stark an die Implementierung gekoppelt sind. Prozesse wie Code Reviews, Interne Schulungen oder Code Katas könnten entgegen wirken.
Man könnte sagen, dass Unit Tests dann schaden, wenn man Unerfahrene Entwickler hat, die als Aufgabe bekommen haben Tests für eine Legacy Code Basis zu schreiben.
Aber Unit Tests an sich alleine sind gut, solange man weiß wie man diese schreibt.
Hey Daniel,
der Wartungsaufwand entsteht sowohl bei Erweiterungen als auch bei Anpassungen. Eine Erweiterung kann ja entweder bedeuten, komplett neuen Quellcode zu schreiben oder eben bestehenden Quellcode um neue Aspekte oder Funktionen zu ergänzen - dann tritt genau dieses Phänomen auf. Ich habe derzeit beispielsweise ein Projekt, bei der über 45.000 (sehr gute) Tests geschrieben wurden und jetzt für das nächste halbe Jahr die Tests deaktiviert wurden, weil die Deadline aufgrund der komplexen Erweiterbarkeit durch die Tests nicht eingehalten werden kann. Anschließend werden die Tests dann in 4 Sprints nachgezogen - und das ist definitiv ein Problem :)
Ja, genau das sollte die Kernaussage sein: UT zur Verifikation von Funktionen ist gut, schränkt aber die Erweiterbarkeit/Wartbarkeit ein (dessen muss man sich bewusst sein), werden Sie zur Reduktion von Fehlern eingesetzt bekommt man meist große Probleme.
Gruß David
@@DavidTielke ja, da fehlt mir einfach die Erfahrung! Aber deswegen lohnen sich die Kommentare unter solchen Videos! Vielen lieben Dank für einen Einblick in das "echte leben". Ich hab viel gelernt!
Gerne, genau deshalb liebe ich die Kommentare hier :D
Gruß David
Sehr guter Punkt, danke, David! Du bringst auf den Punkt, was mein Bauchgefühl schon gesagt hatte.
Hallo Christof,
sehr gerne!
Gruß David
Ich bin der Meinung: Unittests können Kontraproduktiv sein. Wie im Video erwähnt habe ich schon oft gesehen dass einfache Änderungen echt viele Probleme mit den Test cases hatten. Ich habe schon ETL Tests gesehen, die für bestimmte Tabellen explizit getestet wurden. Es war grausam neue Spalten hinzuzufügen, zu verändern oder zu entfernen... ein gutes Beispiel von gut gemeint, aber schlecht gemacht.
Auf der anderen Seite hatte ich aber schon oft die Situation, in denen mich ein Unittest auf bestimmte Dinge aufmerksam gemacht hat. In der Objektorientierten Programmierung wird z.B. oft mit Seiteneffekten gearbeitet. Verändert man diese, sind die Auswirkungen auf andere Module nicht immer klar. Ein fehlschlagender Testcase ist da gold wert.
Zuletzt steht aber die Aussage: Wer testet, schreibt besseren Code. Die Funktionen werden deutlich expliziter und übersichtlicher. Ich sehe in Projekten ohne Testabdeckung oft super lange, verschachtelte und unübersichtliche Funktionen (schlechtes Handwerk) und in Funktionen mit Testabdeckung wesentlich schöneres :D
Fassen wir also zusammen: das notwendige Minimum macht den Mix
Das höchste Pain-Level mit SW-UnitTests erreicht man in der Functional Safety. Hier gilt das V-Model zu 100% und für UnitTests gelten zu dem sehr hohe Anforderungen an die CodeAbdeckung die i.d.R bei Branch-Coverage beginnt und bis zu MC/DC (Automotive/Industrial/Aero-Space, multiple conditon decision coverage) mit Nachweipflichten, Dokumentation, Impact-Analysen reicht...
Stimme dir normalerweise in vielem zu, aber nach 45 Jahren Softwareentwicklung bin ich in diesem Punkt *komplett* anderer Meinung
Hallo Gerd,
das ist gar kein Problem, genau dafür sind ja die Kommentare da. Was ist denn Dein Standpunkt?
Gruß David
@@DavidTielke perrfekte Antwort!
Ich arbeite in der Entwicklung für leistungselektronische Systeme, die im Energieversorgungsnetz arbeiten. Wir machen keine Unit Tests. In der Regel schmiert alles relativ schnell ab, sobald etwas nicht funktioniert. Wir machen umfangreiche Systemtests an automatisierten Testständen, die jede Nacht mit dem aktuellen Build angestoßen werden. Der Rest ist Eigenverantwortung des Entwicklers.
Bei den Bugs die zurückgemeldet werden, würden auch Unit Tests nicht helfen. Die beziehen sich eher auf die Gesamtfunktion des Systems.
Unit Tests sind definitiv keine Pflicht.
Gerade in der startup phase sind unittests voellig sinnlos. Ich nutze eigentlich nur Unittests um automatisierte Programlaeufe zu erhalten die man mit interactiven Sprachen im REPL (Read-Eval-Print Loop) machen wuerde. Anstatt Unittests ist das Program mit vielen, vielen Assert Checks zu testen. An signifikaten Punkten immer wieder Invariant Checks einbauen die die logische Konsistenz ueberpruefen. Das ist das verschmelzen von Design By Contract mit Test Driven Design das funktioniert. Leider kennen viele gar nicht "Design By Contract" da Eiffel ja defacto ausgestorben ist. Da geht gutes Wissen vor die Hunde.
Also wir schreiben unsere Tests überwiegend entlang von Public API (zumindest beim Framework, da ist die Kritikalität grundsätzlich hoch). Dann können wir unter der Haube alles komplett refactorn und die Tests zeigen uns im Idealfall an, wo wir Verhalten geändert haben. Unit Tests im engeren Sinne vermeinden wir deshalb.
Das Schreiben von wirklich guten Unit Tests, welche die genannten Nachteile vermeiden, ist etwas für Profis.
Hallo David, du sagst, dass neue Features bestehende Unit-Tests kaputt machen können und sie deswegen repariert werden müssen. Das klingt für mich, als hätte man zuvor das Single Repsonsibility Principle verstoßen.
Hey,
das kann ein Grund sein aber natürlich kann es auch zeigen das die ursprünglichen Erwartungen nicht mehr passen. Letzteres ist ja genau das, was wir bezwecken wollen aber trotzdem erhöhen wir damit den Wartungsaufwand.
Gruß David
Genau das!
Das Video kommt gerade richtig, denn ich s(chwi)tze gerade über den Unit Tests.
Ich finde UnitTests im großen und ganzen sinnvoll. Sie haben mir schon geholfen, Schwachstellen im Code zu entdecken. Zum Beispiel indem man in Kombination mit Code Coverage entdeckt, dass bestimmte Bereiche gar nicht ausgeführt werden. Die 1-2-4 Regel kann sicher auch eine 1-3-9 sein. Insofern gebe ich David recht.
ABER: Es gibt bestimmte Anwendungen, insbesondere wenn es sich dabei um Produkte im Medizinbereich handelt, die zudem in den USA vertrieben wird, wo Unit Tests zwingend vorgeschrieben sind. Die FDA lässt grüßen. Allerdings sind deren Unit Tests mit denen von z.B. Visual Studio nicht identisch. Die FDA meint nämlich das Testen von Units und nicht Unit Tests.
Trotzdem wünscht sich die FDA eine 100%ige Code Abdeckung.....
Mein Problem ist weniger das Schreiben der Tests, auch wenn es sehr aufwändig ist. Mein Problem ist: wie dokumentiere ich die Tests selbst und deren Ausführung/Ergebnis.
Ohne VS Ultimate ist man auf 3rd Party angewiesen (z.B. ReSharper und seine Tools). Aber selbst dort ist der druckfähige Output mehr schlecht als recht.
Also erstellt man sich eigene Tools, um die per Batch erzeugten wenigen Details einer Test-Ausführung irgendwie lesbar zu Papier zu bringen.
Und das hält enorm auf! Als alleiniger Entwickler bin ich von allen Teilen der 1-2-4 betroffen.
Und in Bezug auf den Kommentar von Ma Ma bezüglich trivialen Code: ich gebe dir recht, aber diesen zu testen erhöht meine Code Coverage Statistik und ist im Allgemeinen schnell implementiert ;)
@@MaMa-rc4eo "schnell" ist relativ. Wie erwähnt bin ich "alleine" unterwegs und schreibe und übersetze (DE->EN) "nebenbei auch noch die Hilfedatei, due Release Notes, Installationshandbuch , ... und erstelle auch Self-Learning Material.
Für die Unit Tests hätte ich gerne einen Kollegen/in, aber seit Jahren passiert nichts......
Das, was mich am meisten aufhält ist die Recherche nach geeigneten Tools für die zusätzlichen CE/FDA Tätigkeiten. Oder zumindest jemand, mit dem man mal offline darüber chatten und sich austauschen kann. Letztlich höre ich hinterher immer, ob nicht noch dieses oder jenes möglich wäre, weil CE/FDA das auch noch gerne hätte oder in einem anderen Format. Um es von Anfang an richtig zu machen gibt es kein Geld. VS Ultimate, ohne es konkret zu wissen, könnte vermutlich vieles per Knopfdruck und ohne 3rd Party erledigen. Und es wäre aus einer Hand.
Hallo Markus,
bin bei allen Punkten bei Dir, leider kommt aber wohl die Kernaussage nicht so wirklich rüber: Unit Tests sind sehr gut, aber sobald im Design Fehler sind und man anfängt die daraus resultierenden Probleme mit Unit Tests zu bekämpfen, gerät man in große Probleme :)
Gruß David
Der Aspirin-Vergleich ist gut, ich sehe aber als Hauptursache die mangelnde Bereitschaft der Softwareindustrie, sich mit der formalen Verifikation von Software zu befassen. Solange dieser Zustand anhält, werde ich auf automatische Tests nicht verzichten wollen. Den genannten Nachteilen stimme ich zu, das Hochrechnen der 1-2-4 Regel widerspricht jedoch in krasser Weise meinen Erfahrungen, eher das Gegenteil ist der Fall.
Ich find den Aufhänger etwas merkwürdig. Es entspricht zwar auch meiner Erfahrung dass solche Ideen rumgeistern, aber man landet da dann doch schnell bei bei der Diskussion rund um die Architektur.
Wenn das Anforderungsmanagement und die Architektur nicht passt, merkt man das woanders auch.
Hat man sich da so rein manövriert dass man das mittels Unittests „beheben“ möchte, stimmt der Aufhänger wieder.
Hey,
ja genau das war ja der Kern des Videos. Auch wenn viele das hier vermuten, ich habe "perse" nichts gegen Unit Tests, sondern nur dann wenn sie in diesen Situationen das Problem nicht lösen und stattdessen Mehraufwände erzeugen.
Gruß David
da stimme ich zu !
Meine Erfahrung ist, dass man automatisch besseren Code schreibt wenn man Unitests hat. Und die unitests kommen natürlich nicht am Schluss, sondern spätestens nach der Hälfte der Programmierung, wenn man schon eine Idee hat, wie man die Aufgaben umsetzen will.
Code nachträglich teststbar zu machen sind nur Schmerzen und ohne sehr große Not mache ich das nicht.
Durch Unitests, die nicht nur Happy path Testing machen, finde ich den Großteil der Fehler, bevor sie meine Kunden finden.
Und noch ein Vorteil: unit Tests sind die einzigen Code Dokumentation, die nie veraltet.
Will ich wissen, wie sich eine Klasse in Grenzfällen verhält schau ich in die Unitests. Wie geht sie bei fehlenden Werten um? Exception oder Fallbackwerte? Nur als Beispiel.
In den Projekten in denen ich gearbeitet habe, hatte ich oft das Gefühl, dass Unit tests nur geschrieben werden, um eine Test Code Coverage zu erfüllen, die von einem corporate requirement vorgegeben wird.
Ich habe Zweifel dass das sinnvoll ist :(
Sehr gutes Video! Stimme mit den meisten Punkten zu deiner Sichtweise mit Unit Tests überein. Dachte schon ich wäre einer der wenigen Entwickler auf diesem Planeten der Unit Tests kritisch sieht. Bin froh das ein Experte wie du da ähnlicher Meinung ist wie ich 🙂
Für manche Entwickler mögen Unit-Tests unabdingbar sein (kann ich selbst nicht so gut bewerten, da in den letzten 7 Unternehmen in denen ich gearbeitet habe Tests immer nur optional gehandhabt wurden), aber nur weil ein Stück Software eine hohe Ausfallsicherheit besitzt, heißt das nicht automatisch, dass die Wartung und Handhabung dadurch besser wird. Sowas entscheidet mehr eine vernünftige Struktur, ein gutes Regelwerk zur Handhabung von Sourcecode und die Ausbildung der jeweiligen Entwickler. Stimme da zu 100% zu.
Amen!
Genau das wollte ich damit sagen und besonders das bei der ungeeigneten Struktur die Sachlage vollkommen anders ist und es mitunter eher gefährlich ist.
Gruß David
Super Video. Wann sollte man anstelle von unit tests auf integrations bzw. end to end tests setzen?
Nehmen wir mal an man bekommt keine vorgaben bzgl. der testabdeckung und befindet sich im microservice Umfeld - was wäre so das absolute Mindestmaß im Industrie Standard um die Qualität aufrecht zu erhalten ohne testfälle per Hand durch testen zu müssen?
So - kurzes Video zu Ende geguckt - und Zustimmung: bei einem kaputten Projekt bringen UnitTests nichts.
Hey Steffen,
bin froh das zu mindest bei einigen die Kernaussage rübergekommen ist, da muss ich wohl doch etwas mehr am Videoaufbau arbeiten :)
Gruß David
"Meetings are terrible, so schedule another meeting right afterwards."
(just kidding, I also operated with this workflow for a while - I prefer shorter and smaller stand-ups thouhg, and just blocking everyone's time for adhoc afterwards)
1-2-4 er Regel würde ich gern belegt sehen, da Du sie ständig nutzt und darauf Deine Argumentation gründest
Hallo David,
late to the party, so ist das, wenn man zwischendurch mal relativ frisch abonnierte Kanäle durchforstet. Trotzdem -- du scheinst eine falsche Vorstellung davon zu haben, wie man Tests schreibt. Tests, auch Unit Tests sollten möglichst gar nicht mit dem Code gekoppelt sein. Tests sollten ein Verhalten nachprüfen, also der Frage nachgehen, welche Ausgabe erwarte ich bei welcher Eingabe. Wenn also irgendwo eine Änderung gemacht wird, sollten da nicht ganz viele Tests fehlschlagen, es sei denn, die Funktionalität wird grundlegend geändert. Aber das dürfte bei den wenigsten Änderungen tatsächlich der Fall sein. Oder die Architektur ist eher schlecht, sodass viele Seiteneffekte durch die Änderung entstehen. Aber in diesem Fall haben die Tests ja ihre Aufgabe exakt erfüllt.
Oder habe ich dich falsch verstanden?
Ich kenne die 1-2-4 Regel nicht. Ich kenne AAA Muster, aber das ist wohl nicht das selbe. Außerdem schreibe ich zuerst Tests, danach den Code. Bin aber kein C# Developer, also weiß nicht wie da getestet wird.
Hallo Heinrich,
das AAA Pattern bezieht sich auf die Strukturierung von Tests, die 1-2-4 Regel bezieht sich auf die zu erwartenden Aufwände :)
Gruß David
Hi David,
ich finde man müsste deine Ansichten etwas differenzierter betrachten. Bei deinem angeführten Beispiel mag die These der Unit-Tests stimmen, hier ist aber auch die Ausgangslage nicht ideal. Die Software ist starr und unflexibel sowie vermutlich nicht ansatzweise genug modularisiert, um doch die eigentliche Stärke der Unit-Tests auszuspielen: Ich kann mich auf einzelne Komponenten oder Funktionen verlassen, die ich in meiner Anwendung dann nutzen kann, die Anwendung selbst als Ganzes sollte dann mittels anderer Testmethoden untersucht werden. Die eigentliche Stärke der Unit-Tests liegt bestimmt nicht im Legacy Code, sondern in Verbindung mit Test-Driven-Development in der Neuentwicklung. Hierbei macht sich der Entwickler doch schon vorher Gedanken über testbaren (aka guten?) Code und dessen Randbedingungen. Uni-Tests sind sicher kein Allheilmittel, gut durchgeführt und geplant sind sie allerdings in der Lage, einzelnen (kritischen) Komponenten eine bis zu sehr gute Stabilität zu gewährleisten und diese langfristig sicherzustellen
Hallo Tobias,
leider muss ich bei der Menge der Kommentare hier einsehen, das der Aufbau des Videos nicht besonders gelungen ist. Genau das was Du sagst sollte der Punkt sein, im "normalen" Betrieb liebe ich Unit Tests aber das Problem ist, das wenn das Projekt bzw. das Design nicht in einem optimalen Zustand ist, dann bekommt man extreme Probleme. Das sollte die Kernaussage sein, leider nicht so gut rübergekommen.
Gruß David
@@DavidTielke ja da muss ein Folgevideo her. die Aussagen so wie sie rüberkommen sind sehr gefährlich. Es hört sich nämlich bisschen zu sehr danach an, dass UT nichts bringen. Ich bin davon überzeugt, dass (egal welche Anwendung) 80-90% der entwicklung TDD gemacht werden können, und dass das auch schneller ist. WEIL in einer ordentlichen architektur 80-90% nicht einfach über GUI/IO zu testen sind. und automatisch eine modulare architektur mit pure functions, SOC, SRP, DRY, etc entsteht.
zu oft sehe ich devs die mit stdout, console.log, etc. features rausfummeln die schlecht geschrieben sind, und danach "alibi tests" schreiben.
Ich schreibe Tests vorher und benütze die für die x iterationen bis alles korrekt ist. Frontend nur smoke und unit nur die Rest api
Ich finde den Videotitel etwas irreführend.
Wir haben auch alten Code aus den 90ern "geerbt", bei dem Unit-Tests sinnlos wären, weil der Code dermaßen ineinander verbastelt ist, dass sich schlichtweg keine *sinnvollen* Unit-Tests schreiben ließen, selbst wenn man wollte. Die können wir praktisch nur über Integrations-Tests testen. Die Software macht die meisten Probleme, weil Änderungen/Erweiterungen so eine Art 4D-Mikado sind: Man zieht ein Mikado-Stäbchen aus dem Haufen am Wohnzimmertisch und in der Küche fällt ein Glas aus dem Regal ;-) ... refactoring ongoing ...
Auf der anderen Seite muss ich aber sagen, dass jene Projekte, bei denen ich von Anfang an mit Unit-Tests gearbeitet habe, die problemlosesten sind. Sie lassen sich mit dem geringsten Aufwand warten und ergänzen. Da kann ich ohne Probleme Features dazubauen und ergänzen - wenn meine Unit-Tests nicht anschlagen, kann ich mir schon zu 90% sicher sein, dass auch die folgenden Integrationstest funktionieren werden.
Wir haben aber ohnehin eine automatisierte, mehrstufige Teststrategie in der Firma (numerische Simulation): Unit-Tests, Commit-Tests, Nightly-Tests (die laufen einmal in der Nacht, weil die mehrere Stunden brauchen), Weekly-Test (die laufen Tage). und dann noch Long-Running - da kann ein einzelner Test auf einem Cluster schon mal mehrere Tage lang laufen.
Ich stehe Unit-Tests auch ambivalent gegenüber, aber dieser Argumentation kann ich nicht folgen. Das ist ungefähr so, als wäre es schlecht, einen Gesundheitscheck beim Arzt zu machen, und der Arzt dürfte kein Stetoskop benutzen und keine Labortests veranlassen.
Unit-Tests sagen mir, ob eine Funktion so läuft wie erwartet. Wenn bei größerer Refaktorisierung die Tests erwartungsgemäß fehlschlagen, ist das kein Unterschied, ob ich das ignoriere oder sowieso keine Tests habe, es sei denn, die sind so fest in der Build Pipeline verankert, daß ein Deployment gar nicht mögich ist.
Warum ich Unit-Tests nicht der Weisheit letzter Schluß finde, ist daß die Architektur um jeden Preis an die Testbarkeit angepaßt wird. Umgekehrt würde ein Schuh draus. Die Architektur muß die Anforderung der Softwarelösung abbilden. Die Tests müssen so gestaltet sein, daß sie die gegebene Architektur testen können. Das bieten Unit-Test-Frameworks meistens nicht. Sie müßten an jede Codestelle springen können und an beliebiger Stelle abbrechen. Ich muß testen können, ob die if-Bedingung korrekt funktioniert, ohne daß der Code im Block ausgeführt wird. Ich muß den Block testen können, ohne von der Bedingung anhängig zu sein.
Ich finde die 1-2-4 Regel sehr spannend. Hast du einen Link, wo das näher erläutert wird?
Link nicht, nutze das schon seit Jahren - urspünglche Quelle ist (glaube ich) "The Art of Unit Testing", aber kann diese aus meinen Projekten bestätigen.
Gruß David
Ich sehe das auch, aber ich weiß nicht wie ich das richtig ausgebe. Wie hast du gelernt so überzeugend zu sein?
@DavidTielke alles schön und gut,
aber ich glaube nicht, dass viele unit tests brechen sollten, wenn ich ein feature ändere. dann sind das keine unittests. unit tests sollten isolierte einheiten testen.
wenn das so ausstrahlt, dann ist was mit den unit tests faul.
regressionstests, e2e tests und integrationstests brechen (in absteigender ordnung) viel öfter
Schöner Upload David!
Danke :)
Gruß David
Sehe ich anders.
1) jeder Entwickler testet. Oft am lebenden System, manchmal mit einem REPL Ansatz, aber niemand schreibt Code und probiert ihn nicht aus. Der Sprung von nem dreckigen Testbett hin zu einem formalen Test den man auch einchecken kann, ist nicht sooo riesig, und dafür wiederholbar.
2) das Argument mit der Aspirin ist schon gut, aber ich halte es schon für schwer (wenn auch nicht unmöglich), dass man Tests schreibt ohne etwas über besseren Code zu lernen.
3) Code lügt nicht. Habe noch nie ne korrekte Entwicklungsdoku gesehen, aber Tests machen verifizierbare Aussagen übers System.
Wenn man für das Hinzufügen eines Features eine ganze, ganze Menge Unit-Tests fixen muss, schreibt man die Unit-Tests falsch.
Eine sehr komische Ansicht. Testing sind ja genu dazu da, Fehler überhaupt zu erkennen.
„So viel wie nötig so wenig wie möglich“
Happy coding
Generell sollte der Entwickler seinen Code nicht selbst testen. Das sollte immer ein anderer Entwickler tun, der den zu testeten Code nicht kennt.
Das nennt man dann eher ein Review. Unit-Tests, Integration-Tests sind ein anderes Thema.
Lustig, sehe es ganz anders. Klar, bist Du langsamer mit Unit-Tests, aber Unit-Tests waren nie als zeilenweise Abdeckung Deiner Klasse gedacht. Sondern zur Abdeckung Deiner Unit ... Zb des Moduls.
Unser Code ist so gut, den braucht niemand testen.
Ja was nu, lieber „langsam“ korrekten Code liefern oder „schnell“ Bugs liefern? Scheint mir ne ausgesprochen abgehobene und Managersicht ohne Praxisbezug zu sein.
Ja, absolut - du hast mich entlarvt! Genau für diese Managersicht bin ich bekannt.
Aber ernsthaft, natürlich bringt es nichts, für einen BBoM Unittests zu schreiben und Accessormethoden von Valuetypes werden durch andere Tests automatisch mitgetestet, weil es sinnlos ist, Valueobjects zu mocken. Aber alles, was Verhalten hat, profitiert durch Unittests. Und sollte es das nicht tun, dann ist es wohl entweder zu klein um eigenständig zu sein oder zu groß und tut zu viel.
Ausnahmen sind interessant und selten. ;-)
Ich finde es ganz erfrischend, wenn die heilige Kuh mal ein wenig gegrillt wird.
Ich hatte auch schon länger insgeheim auf das "Tod durch Unit Tests" gehofft.
Kann man das nicht umbenennen in "Paralyse durch Unit Tests" und einen Disclaimer davor hängen?
Ich durfte mal eine Test-Hölle kennenlernen, bestehend aus Unit-Tests, Integration-Tests und n2n-Tests.
Meine spektakulärsten Werte waren:
- Ein halber Tag Implementierung und vier Tage Tests angleichen.
- Zwei Tage Implementierung und zehn Tage gegen die Test ankämpfen, die ich dann letztendlich beinahe unbrauchbar gemacht hätte.
- - Ohne Hilfe eines alteingesessenen Insiders ging da nichts mehr.
Wenn man am Legacy Code zugange war, ging flugs die Coverage runter.
Das musste man dann beim zeitlich überlasteten Team Lead extra beantragen, damit der das durch die Pipeline winkt.
Kein Spaß das. Und ganz offensichtlich aus tiefster Not geboren. Zu Haufe höchst kritischer Geschäftsvorgänge verteilt in einer schwer durchdringbaren Codebase. (Hohe Kopplung quer durch die Landschaft. Zu Haufe Gigabyte schwere MySQL-Tabellen die sich ganz weit waagerecht scrollen lassen. Also das was man so liebt. :-D )
--------------------------------------------------------------
Hat nicht Uncle Bob Martin die Legende in die Welt gesetzt, TDD hätte keinen zeitlichen Mehraufwand? Ich kriege davon ein flaues Gefühl im Magen.
Ich hatte in meinem jetzigen Betrieb von einem Entscheider den Spruch "Das sollten wir in TDD manchen, weil das besseres Code Design erzwingt."
Also Dependency Injection allein macht kein gutes Code Design. Oder?
Und TDD um jeden Preis führt dazu, dass ggf. schlechtes Code Design betoniert wird. Ich hatte da einen Fall, wo ein fettes JSON als Testeingabe von einer 500-Zeilen-Methode verwurstet wurde. Zyklomatische Komplexität vom feinsten. OK, so was sind vermeintliche Unit Tests und in Wahrheit schlecht wartbare Integration Tests. Macht es auch nicht besser.
Dann kommt gerne mal das das Wort von "mit TDD bin ich schneller". Tja, ist ja schön für dich, aber was ist mit mir?
Betretene Stimmung nachdem ich im Zuge eines umfassenden Refactorings, der kaum einen Stein auf den anderen ließ, alle zugehörigen "Unit Tests" ersatzlos weggeworfen hatte.
Tests, die nur alteingesessene Entwickler lesen können???
Ich glaube, da ist was kräftig schief gelaufen.
Gerade die Tests sollen leicht verständlich sein.
Hilfreich ist dabei sind natürlich, SRP und Co. im Projekt zu benutzen.
Kompliziert wird es ein wenig beim Mocken.
Mir kommt es so vor, als bist Du nur Froh, dass David die Tests etwas schlechter macht, weil Du sie nicht magst.
UnitTests sind Tests auf unterster Ebene und sind keine Integrationstests o.ä..
Unit Tests sollen Funktions gebunden sein und nicht über eine Gruppe von Funktionen.
Genauso umgekehrt. Daher weiß ich nicht, wenn man eine Änderung in einer Methode macht, das man mehrere Tage an vielen UnitTests sitzen muss?
@@marcusreinicke genau, frei nach dem motto ah ich brauch keine tests, gugg ich mir später an was alles knallt, und oh jetzt muss ich aber vier Tage Tests angleichen. Klarer Fall von Ignoranz und dann braucht man sich auch nicht beschweren das man so lange Tests fixen muss :) Besser kleine Änderungen und iterativ laufen lassen.
> "Mir kommt es so vor, als bist Du nur Froh, dass David die Tests etwas schlechter macht, weil Du sie nicht magst. "
Das muss ich in aller gebotenen Höflichkeit zurückweisen, auch wenn mir im realen Leben wegen meiner kritischen Haltung ein wenig der Ruf anhängt, dass ich "keine Tests mag". Ich mag nicht, wenn die Dinge aus dem Ruder geraten. Ich habe ja reale Fehlschläge aufgezählt und Du hast die ja in Deiner Antwort z.T. bestätigt.
Ich habe generell was gegen "Religion". Damit meine ich: Nichts ist Kontext-unabhängig. Jedwede Technik, jedwede Vorgehensweise bedarf eines Kontextes, in dem sie funktionieren kann. Ist der Kontext nicht gegeben ist entweder der Kontext herzustellen oder Technik/Vorgehensweise wegzulassen.
Wenn eine "TDD Religion" dazu führt, dass Entwickler mit der Auffassung "mit TDD liege ich immer richtig" bei einem 100%-Bottom-Up-Approach (~ "null Vorplanung") gegen eine externe Black Box coden und ein resultierender "Unit Test" eine 500-Zeilen Methode mit einem komplexen JSON als Eingabe testet, dann habe ich was dagegen. Dann gibt es Klärungsbedarf.
Wenn ich kämpfen muss, damit ich meine injizierten Abhängigkeiten sinnvoll gemockt bekomme, dann ist das ein Zeichen, dass evtl. erst ein anderes Problem zu lösen ist. Oder die Sinnhaftigkeit von Unit Tests an der betreffenden Klasse ist zu hinterfragen.
Selbstredend sollten die Testfälle "bis aufs letzte Bit" atomisiert sein. Sonst sind es keine Unit Tests. Ich nehme an, "SRP & Co." sind nicht nur hilfreich, sondern Voraussetzung.
Bei meinem "Bericht aus der Hölle" kamen undurchsichtige Workflow-Logik mit undurchsichtigen n2n/Integration-Tests zusammen. Also schlecht mal schlecht multipliziert.
Wäre übrigens durchaus dankbar für Empfehlungen für n2n/Integration-Test-Guides.
@@guidoerfen7944 Methoden mit 500 Zeilen?
Ja gibt es zuhauf in alten Projekten.
Aber Methoden mit 500 Zeilen kann man nicht sauber testen.
In neueren Projekten sollten 500 Zeilen verpöhnt werden.
Da läuft sonst was anderes ganz gehörig schief.
Hallo Guido,
och als grillen empfinde ich es gar nicht, ich genieße die Diskussion hier sehr :) Aber es ist wieder das im letzten Kanalupdate angesprochene Thema, sobald hier etwas kritisiert wird was Entwickler lieben und schätzen werden die merkwürdigsten Dinge in meine Worte interpretiert - hier hatte ich das aber schon erwartet :)
Das mit dem Titel ist leider immer ein sehr schmaler Grad, weil es dann einige wieder als Clickbait empfinden und andere meinen das im Video nicht das Thema behandelt wird, deshalb dachte ich das hier passt am besten.
Gruß David
Da isser direkt gegenüber und schaut nicht mal vorbei... 😪😓😂
Moin Zimpi,
ich habe Dir sogar geschrieben, aber scheinbar hat Du eine neue Handynummer. Wäre gerne mal vorbeigeschneit :)
Gruß David