Laden...

Tatsächlicher Nutzen von Unit-Tests [und TDD]

Letzter Beitrag vor 13 Jahren 186 Posts 53.731 Views

Nicht wenn diese Methoden nur von der UI benutzt werden, und privat sind, wie das weiter blättern Beispiel. Diese sind von der äußeren Schnittstelle nicht abgedeckt.

Naja, die UI ist aber eine äußere Schnittstelle. Die UI bedient sich ja nicht selbst, sondern stellt Elemente öffentlich für den Benutzer bereit, der dann draufklicken kann. Dann bräuchtest du für den Teil (automatisierte) UI-Tests.

...

Genau das selbe könnte ich von dir und deiner Ansicht auch sagen
"Du hast MVVM nicht verstanden" - "Du machst dieses und jenes falsch" =>
wo wir nun bei Vorwürfen angekommen wären.

@dN!3L
Was ändert das daran das die View eigene Methoden hat die sie nur intern verwendet? Diese will ich ja auch Testen.
Da das herkömmliche TabControl auch funktioniert wird MS doch bei der Entwicklung auch Testen.

//Umformulierungen

Nein, das gleiche kannst Du mir nicht vorhalten, weil:
*ich mich seit rund einem dreiviertel Jahr intensiv mit Unittests und TDD beschäftige *von Dir keine einzige relevante Quelle kam, die Deine Meinung bestätigt hätte *ich beide Seiten aus eigener Erfahrung kenne, so wohl das Testen von privatem Code als auch der Verzicht darauf *ich lernfähig bin, was TDD angeht, das habe ich öffentlich genug bewiesen, indem ich über meine eigenen Fehler und meine daraus gezogenen Lehren geschrieben habe *ich mich vor 9 Monaten geäußert habe, dass Unittests und TDD vollkommen überbewertet seien, mir was anderes gesagt wurde, und ich mir das dann zu Herzen genommen habe

All diese Punkte fehlen bei Dir. Insbesondere den letzten vermisse ich.

So lange Du es nämlich nicht anders kennst und Du es nur von vornherein verurteilst, ist es schwierig, zu argumentieren - weil was will man gegen "Ich find das aber gut so" schon groß sagen?

Letztlich musst Du das nicht tun. Wie gesagt, wenn Du glücklich so bist, dann bleib dabei. Nur das dann als allgemeingültiges Gesetz der Form "Es spricht nichts dagegen, privaten Code per Reflection zu testen" zu erheben, wenn alle Welt was anderes sagt, das ist ein bisschen vermessen ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Eigenartig, wenn du doch so einsichtig bist und dich weiter bildest, warum bist du dann so überheblich und wirfst anderen vor das sie dieses und jenes nicht verstehen würden und stellst deine aussage als die einzige richtige dar?

Du hast vermutlich dein Weg gefunden, schön, das heißt aber nicht das es immer der richtige ist, nur weil alle nach plappern.

Das es die Accessor gibt, es das Codeproject artikel gibt die zeigen wie man private Methoden tested zeigt mir ganz deutlich das der bedarf da ist.

Ich zb entwickel nicht nach dem MVVM da ich es nicht brauch, mein code ist in der Code Behind, aber auch absolut getrennt, dh ich könnte es, wenn die nachfrage aufkommt in minuten in ViewModels auftrennen, aber wozu? Genauso nutz ich Service Provider um meinem Code anderes verhalten (für die Units) zu injizieren.

Das alles kannst du nicht wissen, auch nicht das es sich bereits mehrfach bewährt hat (habe bisher alle neuen Anforderungen problemlos einbauen können) entsprechend ist deine Verurteilung "Du machst das falsch" unangemessen und überheblich.

Du scheinst einfach nach der Masse zu schreien.

Wie ich schon sagte: Mach, was Du willst.

EOD

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Hallo CSL und Golo Roden,

ich möchte mich aus der Diskussion raushalten und möglichst neutral bleiben. Mich wundert es, dass du - CSL - immer auf MVVM abgerichtet bist. MVVM ist ja nur die Lösung zum Ziel. Das, was zwischen Lösung und Ziel ist, ist wieder eine andere Sache. Du suchst akribisch nach Möglichkeiten, wo man MVVM nicht verwenden kann. So wie in deinem kürzlich erstellen Thread. Dort habe ich dir die nötigen Hilfestellungen gegeben. Weiter möchte ich dir nicht weiterhelfen. Der Grund ist, dass wenn man schon einen Anhaltspunkt hat - den ich dir gegeben habe - man selber weiter recherchieren kann und somit immer auf eine Lösung kommt. Ob man nun MVVM einsetzt oder nicht, bleibt der Situtation und/oder deiner Meinung überlassen.

Und zum Thema "mit der Mehrheit": Golo hat sicherlich einiges mehr Erfahrungen als du. Das behaupte ich jetzt einfach mal. Wenn er das sagt, dann sollte es schon stimmen. Vielleicht sind deine Meinungen anders, aber was solls.

zero_x

Hallo CSL

Ich bin zwar Schweizer, aber nicht in allen Belangen neutral 😉

Eigenartig, wenn du doch so einsichtig bist und dich weiter bildest, warum bist du dann so überheblich und wirfst anderen vor das sie dieses und jenes nicht verstehen würden und stellst deine aussage als die einzige richtige dar?

Ich habe an keiner Stelle von Golo gesehen, das er seine eigene Meinung als allgemeingültig erklärt,
kannst du mich da bitte erhellen?

Du hast vermutlich dein Weg gefunden, schön, das heißt aber nicht das es immer der richtige ist, nur weil alle nach plappern.

Richtig oder falsch ist hier nicht unbedingt die Frage, sondern ob man überhaupt sauber ans Ziel kommt.
Den Weg von Golo hat er sicherlich nicht komplett selber erfunden, sondern war auch länger auf der Suche danach.
Schlussendlich brauchts ein bisschen ganzheitliches Denken und man hat seine - für sich passende - Lösung.

Das es die Accessor gibt, es das Codeproject artikel gibt die zeigen wie man private Methoden tested zeigt mir ganz deutlich das der bedarf da ist.

Wieso Bedarf?
Die **Möglichkeit **ist von MS gegeben - sie werden es inzwischen auch besser wissen - und wurde von jemanden für gut befunden, so das er einen Artikel darüber schreibt.

Gerade auf Codeproject finden sich IMHO aber häufig unsaubere Lösungen, also sollte man sich nicht nur darauf stützen,
sondern mehrere Quellen anzapfen.

Ich verstehe dich nicht wirklich CSL.

Auf der einen Seite forderst du Hilfe und bist ein selbstgenannter Anfänger / Fortgeschrittener, der noch nicht lange mit Unittests entwickelt. Auf der anderen Seite lehnst du jedwelche Hilfe ab, die - auch wenn du sie als arrogant interpretierst - gut gemeint ist.

Entweder machst du alles selber und lässt das Forum damit in Ruhe, oder aber zu nimmst die Hilfe an,
was ja eigentlich dein Ziel war, oder?

Also ich könnte mir nicht vorstellen, irgendwo eine Frage zu stellen und mit den Helfenden so forsch umzugehen.
Was passiet ist klar, niemand hat mehr Bock auf deine Fragen und zieht sich zurück weil es sinnlos ist, wenn du auf die Fragen von uns nicht reagierst und die genannten Vorschläge nicht näher unter die Lupe nimmst oder ausprobierst.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Genau das isses ja
Mir wird hier andauern vor geworfen ich würde nicht über die Vorschläge nach denken und sie ggf ausprobieren, des weiteren wird behauptet ich könne etwas nicht, wobei ich sagen muss das ihr das keineswegs beurteilen könnt.

Und Golo kam mir die ganze zeit absolut arrogant rüber, und echte haltbare Punkte habe ich auch keine gesehen.

Er erklärt seine Meinung als allgemein gültig weil er behauptet dies ist falsch, jenes ist falsch und das wars auch schon.
Ich les viel allgemeines und noch persönliche Werbung (Habe darüber Gebloggt -> Toll), aber kaum was konkretes.

=> Man sollte über niemanden urteilen dessen arbeit man nicht kennt.

Des weiteren sei genannt das MS es keineswegs bereut, sie schreiben Artikel darüber wie man es macht How to: Test a Private Method und auch VS erstellt selbständig die privaten test Methoden. Wenn man privates nicht Testes kann man in VS 90% der erstellen Klassen erstmal bereinigen.

@zero_x
Ich selber habe nicht von MVVM angefangen, sondern ich sprach nur von Methoden die in Views stecken. Golo hat doch gleich die MVVM Keule geschwungen und gleich oben drein behauptet ich hätte es nicht verstanden.

Gerade du kennst mich doch eigentlich und weißt das ich ein Mann aus der Praxis bin.

(MVVM selber ist mir ziemlich egal da ich es unnötigen Overhead finde, aber das gehört hier nicht her.)

PS. Hilfe gesucht habe ich zudem keine 😉 (Habe gerade nochmal durch geschaut)
Außer: Wie kann man in VS die Überprüfung von Privatem Methoden beim Code Coverage deaktivieren? Scheinbar geht das nicht [ohne den original Code an zu fassen]
Gerade wenn man meint das man privates nicht Testen soll muss es doch eine Möglichkeit in VS geben.

@CSL [ ] Du hast verstanden, worum es geht.

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Hallo zusammen,

interessante Diskussion, ich klink mich mal ein 😉

In einem Tab blätter man auch weiter, nur halt indem man auf die Tab Header klickt, nach deiner Logik müsste das umschalten der Tabs auch ins ViewModel.

Natürlich gehört das in die View, denn sie Zeigt ja die geblätterten Controls an.
Es war tatsächlich zu beginn so das die View alle Controls zuerst in Tabs anzeigte, das hatten wir dann zwecks Übersicht geändert sodass man durch die Liste iteriert.

Öhm... kurz und bündig: Nein! Kann ich überhaupt nicht unterschreiben.

Golo hat dazu schon seine Meinung geschrieben, die ich absolut nicht teile, obwohl wir zum selben Ergebnis kommen 😉

Nein, ein TabControl gehört in die View. Weil es ein Control ist, das etwas anzeigt.

Das ist meiner Meinung nach zu platt (formuliert). Wir müssen uns als Entwickler meiner Meinung nach viel mehr mit der Semantik von Controls auseinandersetzen.

Ein TabControl gehört halt nicht (nur) in die View, weil es von Control abgeleitet ist. Es gehört auch nicht in die View, weil es etwas anzeigt. Der Punkt ist, dass es nichts, aber auch gar nichts anderes tut. Natürlich kann ich durch geschicktes Anordnen der Tabs die Reihenfolge, wie sie durchgeklickt werden sollten nahelegen. Ebenso kann ich visualisieren, wie eng zwei Tabs miteinander verwandt sind, indem ich sie nahe zusammen stelle. Mehr jedoch nicht.

Was ist aber mit den "Vor"- und "Zurück"- respektive "Fertig"-Buttons? Sowas baut man nicht "zwecks Übersicht" ein. Ganz im Gegenteil. Dadurch gebe ich dem Benutzer die Hand und leite ihn. Entweder durch einen bestimmten Prozess oder aber durch ein bestimmtes Schema, welches dem besseren Verständnis dient. Unter Umständen kann ich sogar den "Weiter"-Button nicht klicken, weil eine gewissen Voraussetzung auf der aktuellen Seite nicht erfüllt ist.
Das sind alles Geschichten, die meiner Meinung nach ganz klar nicht mehr der View gehören, das ist Business-Logik.

TabControl und "Vor, Zurück"-Dialog sind also semantisch gar nicht äquivalent. Um es noch einmal zu unterstreichen, erlaube ich mir es nochmals zu zitieren:

nach deiner Logik müsste das umschalten der Tabs auch ins ViewModel.

Nein, weil hinter dem Umschalten der Tabs aufgrund der semantischen Bedeutung eines TabControls keine (Business-)Logik liegen darf.

Nur meine Meinung...

Grüsse,

N1ls

Hallo CSL,

In einem Tab blätter man auch weiter, nur halt indem man auf die Tab Header klickt, nach deiner Logik müsste das umschalten der Tabs auch ins ViewModel.

Wenn das zur Logik gehören soll, kann es ins ViewModel, muss aber nicht. Die Controls dienen dazu, etwas visuell, schmatisch, strukturiert und nach bestimmten Verhalten anzuzeigen. Logik ist einerseits auf der View selbst und andererseits Logik in einem ViewModel. Sonst kann man ja direkt die komplette Logik im Code-Behind definieren. Erstmal sollte man sich fragen, wozu Controls dienen.

zero_x

@N1ls: Endlich mal eine gute Begründung, welche dieser unnötigen MVVM Diskussion ein Ende macht.

Ich denke Controls wären nach CCD das bestmöglichste Beispiel für schlechten Code. Steuerelemente mit wahrscheinlich mehr als 10 Tausend Zeilen Code in einer Klasse sind keine Seltenheit, man muss sich nur mal die Grids von Infragistics ansehen.

Ich tue mir gerade mit Controls sehr schwer. Da ich auch noch hauptsächlich mit Silverlight und neuerdings Windows Phone arbeite und dort Unit Tests mehr als nur keinen Spaß machen neige ich leider dazu das Thema bei Controls auszulassen.

Und das leider obwohl ich Dank meines früheren Arbeitgebers mit Unit Tests vertraut bin und sie schätzen gelernt habe. Das schmerzt schon sehr aber irgendwie war der Stress mit Silverlight Unit Tests und Controls bisher höher.

Bei normalen Komponenten habe ich meist relativ isolierte Methoden oder auch komplexere Operationen. Bei Steuerelementen kommen leider viele Abhängigkeiten zu Zuständen dazu (Beispiel: DragDrop, IsMousePressed, IsOverTarget, IsOverSource etc.). Da fehlt es auch an einer sauberen Darstellung dieser Abhängigkeiten und wenn dann noch Xaml dazu kommt muss man extrem passiv programmieren was das Testen auch nicht einfach macht.

Oh. Es gab ja noch antworten, gar nicht gesehen 😄

Was ist aber mit den "Vor"- und "Zurück"- respektive "Fertig"-Buttons? Sowas baut man nicht "zwecks Übersicht" ein. Ganz im Gegenteil. Dadurch gebe ich dem Benutzer die Hand und leite ihn. Entweder durch einen bestimmten Prozess oder aber durch ein bestimmtes Schema, welches dem besseren Verständnis dient. Unter Umständen kann ich sogar den "Weiter"-Button nicht klicken, weil eine gewissen Voraussetzung auf der aktuellen Seite nicht erfüllt ist.
Das sind alles Geschichten, die meiner Meinung nach ganz klar nicht mehr der View gehören, das ist Business-Logik.

TabControl und "Vor, Zurück"-Dialog sind also semantisch gar nicht äquivalent.

Da ist eben der unterschied, unser Vor/Zurück hat keine Logik die ein Button deaktiviert oder ähnliches, es zeigt nur an, es hat genauso viel Funktionalität wie das TabControl, es ist praktisch genau das selbe, nur das der User nicht weite Sprünge machen kann. Man könnte es direkt mit ein TabControl austauschen und nichts würde sich verändern, es würde nur die Übersicht leiden da es zu viele Objekte sein können.
"Fertig" gibt es auch nicht, es ist kein Wizard sondern nur eine andere Ansicht der Daten.
Auch der Logic dahinter ist völlig desinteressiert welches Objekt gerade angezeigt ist, für die Logic ist es einfach eine Liste von Objekten, die View kann es in einer ListBox oder einem TabControl konsumieren.

Tatsächlich hat dieses Control weniger "Logik" als alle WPF Controls (z.b.: das StackPanel).

Ich könnte das Control so wie es ist auch in Tulipa packen und für die Applikation würde sich nichts ändern 😄

Ich würde aber vor schlagen das Thema hier sein zu lassen, da das nicht mehr zum Thema gehört.

Ursprünglich hatte ich aber diesen Thread aber gesucht weil ich nur was erzählen wollte.
Ich entwickel seit nun einiger Zeit nach TDD (wie schnell die Zeit vergeht -.-) und muss sagen das macht echt Spaß, hat sich gelohnt dort rein zu schnuppern 😃
Man überlegt auch viel mehr wie man etwas auf zieht statt einfach los zu legen. Ich würde nicht sagen "Nie ohne" aber eine angenehme art der Entwicklung ist es schon 😃

Hallo,

gibt es ein paar Empfehlungen, wie man sich als Newbie dem Thema Unit-Tests und TDD nähert (Literatur, Software)?

Grüße, Koller.

Also ich habe mich mit "Test Driven Development" von Kent Beck eingearbeitet, kann es absolut weiter empfehlen 😃 Es ist auch Unabhängig von irgend einer Library, dh du kannst es mit MSTest machen oder mit NUnit, spielt keine Rolle.

gibt es ein paar Empfehlungen, wie man sich als Newbie dem Thema Unit-Tests und TDD nähert (Literatur, Software)?

Was ich sehr empfehlen kann, ist das Buch "Pragmatic Unit Testing". Warum, wieso, weshalb - siehe Review von Pragmatic Unit Testing

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Hallo,

danke euch beiden. Ich werde mir beide Bücher mal anschauen.

Grüße, Koller.

Ich kann Golo nur zustimmen, das Buch ist sehr gut.
Habe zwar nicht die Ausgabe fuer C# sondern fuer Java gelesen, aber das sollte ja egal sein, es geht um den Kerngedanken, alles andere ist Syntax.

be the hammer, not the nail!

Hinweis von gfoidl vor 13 Jahren

Vorsorglicher Hinweis: Bitte macht keine Buchbesprechung daraus und bleibt beim Thema. Danke.

[Nein, habe mir aber fest vorgenommnen es einzuführen]

Ich habs bisher oft gemieden aus den bereits genannten Gründen bzgl. der Erkenntnis. 😃
Dieser Thread hat mich umgestimmt sodass ich mir vorgenommen mich in das Thema (nochmal) einzuarbeiten.

Meine bisherigen Hürden zu TDD ist einfach dieser Mehraufwand und wenn man wirklich TDD programmiert, dann ist das ein Graus wenn man nicht unterstützende Tools wie zB. Resharper hat weil für Klassen, Methoden die es noch nicht gibt, kann es logischerweise keine Intellisense geben und so dichtet man sich was zusammen in einem Test, und muss es nachher (teilweise) nochmal ausprogrammieren.

Naja mal schauen wie konsequent ichs diesesmal durchziehe.

Lg XXX

Die Tests kommen zwar vor der Implementation, aber nach dem Design der Architektur.
Und dabei werden die Interfaces geschrieben, und auf die beziehen sich dann auch die Tests.

Genau, also man erstellt im Test dann Objekte und benutzt Methoden die es noch nicht gibt, aber man hat meist vorher schon eine konkrete implementations Idee.

Was mir dabei gefällt ist das man in der Test Methode bevor man etwas erstellt alles nochmal überblickt um dann von den Best Case der Benutzung aus zu gehen.
In VS kann man dann auch mit CTRL+. -> New Type direkt die neue klasse und dessen Methoden in das Ziel assembly rein erstellen lassen.

Ich hatte es schon öfter das ich ne Klasse aus dachte die etwas macht, und als ich dann die Test methode fertig hatte (die konkreten Objekte noch nicht) merkte ich das eine leicht andere verwendung des Objektes viel angenehmer ist, dann hab ich das angepasst und erst als ich glücklich damit war das konkrete Objekt erstellt.

Zu beginn ist man zwar langsamer, aber das gleicht sich schnell aus, man muss sich auch daran erst gewöhnen.

Man löst Probleme auch von der anderen Richtung, ich für mein Fall hatte oft mit der UI angefangen und dann stück für stück zur Funktionalität vor gearbeitet. Jetzt erstell ich erst die Funktionalität und muss dann nur noch eine UI davor packen.

Man löst Probleme auch von der anderen Richtung, ich für mein Fall hatte oft mit der UI angefangen und dann stück für stück zur Funktionalität vor gearbeitet. Jetzt erstell ich erst die Funktionalität und muss dann nur noch eine UI davor packen.

Wenn TDD zu einem solchen Verhalten führt, dann werden dadurch natürlich erhebliche Mehrkosten verursacht. Entwicklung vom User Interface in Richtung Backend ist effizient, weil
*keine Funktionalität implementiert wird, die nicht benötigt wird *seltener nachträgliche Änderungen gewünscht werden(wenn das UI vom Kunden abgenommen ist, man im Backend relativ frei)

Alleine die Auffassung "nur noch eine UI davor packen" widerspricht jeglichen agilen Prinzipien. Und TDD kommt nun einmal aus genau dieser Richtung.

Von daher finde ich es natürlich falsch, hier im Thread zu suggerieren, TDD wuerde die Entwicklungsweise in dieser Hinsicht quasi umkehren.

Da ist eben der unterschied, unser Vor/Zurück hat keine Logik die ein Button deaktiviert oder ähnliches, ...

Genau DAS meinte ich. Wenn keine Logik, dann ist es sinnlos mit Vor- und Zurück-Buttons zu arbeiten. Mindestanforderung, um soetwas einem TabControl vorzuziehen ist eine notwendige Sequenz.

Ich würde aber vor schlagen das Thema hier sein zu lassen, da das nicht mehr zum Thema gehört.

Ich denke diese gehört eng zusammen(wieso sonst sollte es hier aufgetaucht sein?). Der Nutzen von Unit-Test hängt auch mit dem Verständnis von verschiedenen Controls zusammen. Ich muss zum Teil die Business-Logik aus diesen Controls rausziehen, um wirklichen Nutzen aus TDD oder überhaupt Unit-Tests ziehen zu können.

MfG,

N1ls

Hinweis von herbivore vor 13 Jahren

Der Aufruf, beim Thema zu bleiben, ist berechtigt und jeder möge ihn sich bitte zu Herzen nehmen. Natürlich muss man, wenn man über den Nutzen von Unittests (und TDD) spricht, auch über deren (Aus-)Wirkungen sprechen. Das ist unbenommen. Man kann das aber auch übertreiben. Wenn es dann nur noch um MVVP oder das Design von Anwendungen geht, dann hat sich die Diskussion zu weit entfernt. Bei allem was man schreibt, sollte daher man den direkten Bezug zu Unit-Tests/TDD nicht nur (im Blick) behalten, sondern immer auch explizit nennen.

Wenn TDD zu einem solchen Verhalten führt, dann werden dadurch natürlich erhebliche Mehrkosten verursacht. Entwicklung vom User Interface in Richtung Backend ist effizient, weil [...]

Kann ich nicht so unterschreiben.

keine Funktionalität implementiert wird, die nicht benötigt wird

Erst Planung dann Implementation, dn man implementiert die Funktionalität die vor gesehen ist als erstes, die UI kommt dann viel später. Man schreibt keineswegs unnötige Sachen.

seltener nachträgliche Änderungen gewünscht werden(wenn das UI vom Kunden abgenommen ist, man im Backend relativ frei)

Änderungen egal wo muss man immer an gehen, wenn die Funtionalität bereits steht ist jede Anpassung der UI absolut einfach, und in sehr kurzer Zeit zu realisieren.

Alleine die Auffassung "nur noch eine UI davor packen" widerspricht jeglichen agilen Prinzipien. Und TDD kommt nun einmal aus genau dieser Richtung.

Von daher finde ich es natürlich falsch, hier im Thread zu suggerieren, TDD wuerde die Entwicklungsweise in dieser Hinsicht quasi umkehren.

Hä? Es fördert doch ungemein die unabhängigkeit, man schreibt seine Funktionalität und muss dann mit nem Designer nur noch die Schnittstelle auskeksen.
Zudem schließt das alles nicht aus das man die Funktionalität nicht noch erweitert oder anpasst nachdem die UI steht. Man schafft mit "Erst Funktionalität dann UI" schon eine solide Basis.

Da ist eben der unterschied, unser Vor/Zurück hat keine Logik die ein Button deaktiviert oder ähnliches, ...

Genau DAS meinte ich. Wenn keine Logik, dann ist es sinnlos mit Vor- und Zurück-Buttons zu arbeiten. Mindestanforderung, um soetwas einem TabControl vorzuziehen ist eine notwendige Sequenz.

30 Items in einem TabControl ist aber absolut unübersichtlich, und eine ListBox+ContentControl wurde abgelehnt, die Konsequenz ist ein Control wo man durch Blättert.

Ich denke diese gehört eng zusammen(wieso sonst sollte es hier aufgetaucht sein?). Der Nutzen von Unit-Test hängt auch mit dem Verständnis von verschiedenen Controls zusammen. Ich muss zum Teil die Business-Logik aus diesen Controls rausziehen, um wirklichen Nutzen aus TDD oder überhaupt Unit-Tests ziehen zu können.

Versteh ich das richtig, nur wegen den Controls siehst du kein Nutzen von TDD und UnitTests? Controls sind mit der kleinste Teil einer Applikation!

Ich warte das auch noch andere TDD Menschen (am besten erfahrene) sich hier zu Wort melden 😁

Hallo N1ls,

Alleine die Auffassung "nur noch eine UI davor packen" widerspricht jeglichen agilen Prinzipien. Und TDD kommt nun einmal aus genau dieser Richtung.

TDD sagt erstmal nichts darüber aus, ob man Top-Down oder Bottom-Up entwickelt. Es sagt nur, dass du den Test vor der Implementierung schreibst. Gerade wenn du sagst, dass bei der Entwicklung "vom User Interface in Richtung Backend" "seltener nachträgliche Änderungen gewünscht werden", bedeutet das doch, dass das das gewünschte Verhalten (gerade auf den oberen, gui-nahen Ebenen) von Anfang an feststeht (und sich nicht mehr ändert). Das sind doch optimale Voraussetzungen, um dieses Verhalten in Forms von Tests auszudrücken und damit auch zu fixieren. Also nochmal, nur weil du TDD verwendest, musst du nicht Bottom-Up arbeiten.

herbivore

Was ich meinte hat mit Bottom-Up/Top-Down nichts zu tun, mir geht es darum das man erst Funktionalität macht und dann den Aufruf.
Das kann bei MVC der Controller sein, und bei MVVM das ViewModel oder direkt eine Klasse in der Logik, spielt keine Rolle wo man anfängt. Das ist ja das schöne dabei, man hat auch mit TDD weiterhin alle Freiheiten.
Eventuell habe ich mich da nicht deutlich genug ausgedrückt, sorry dafür.

Vorher hatte ich immer erst die UI gemacht und die Controls mit Commands und dort mit Methoden verbunden und das dann aus implementiert. Das hatte den nachteil das ich die UI immer wieder anpassen musste und es fester verdratete sodass es schlechter testbar war. Jetzt Fang ich tiefer an, ich kann so die UI machen wenn es definitiv nicht mehr geändert wird (also nicht geplant) und hab gleich meine volle test Abdeckung -> aber es muss nicht so tief sein das es gleich Buttom-Up ist.

Hallo herbivore,

Alleine die Auffassung "nur noch eine UI davor packen" widerspricht jeglichen agilen Prinzipien. Und TDD kommt nun einmal aus genau dieser Richtung.
TDD sagt erstmal nichts darüber aus, ob man Top-Down oder Bottom-Up entwickelt. Es sagt nur, dass du den Test vor der Implementierung schreibst.

Ich habe nicht behauptet, dass TDD eine Richtung vorgibt. Es kommt aber aus der agilen Softwareentwicklung und dort geht es u.A. darum kontinuierlich Nutzen zu produzieren. Das kann ich eben nicht, wenn ich zuerst mit TDD das komplette Backend fertige und dann das UI anfange. Im schlimmsten Falle ist Release-Termin, wenn ich mit dem Backend gerade durch bin... das heisst dann, ich habe noch überhaupt keine Funktionalität geschaffen, jedenfalls keine für den Kunden nutzbare.

Gerade wenn du sagst, dass bei der Entwicklung "vom User Interface in Richtung Backend" "seltener nachträgliche Änderungen gewünscht werden", bedeutet das doch, dass das das gewünschte Verhalten (gerade auf den oberen, gui-nahen Ebenen) von Anfang an feststeht (und sich nicht mehr ändert). Das sind doch optimale Voraussetzungen, um dieses Verhalten in Forms von Tests auszudrücken und damit auch zu fixieren. Also nochmal, nur weil du TDD verwendest, musst du nicht Bottom-Up arbeiten.

Das ist ja genau meine Meinung. Und so gehe ich bzw. versuche ich möglichst vorzugehen. Deshalb finde ich es auch Schade in Bezug auf TDD etwas zu lesen wie

Man löst Probleme auch von der anderen Richtung, ich für mein Fall hatte oft mit der UI angefangen und dann stück für stück zur Funktionalität vor gearbeitet. Jetzt erstell ich erst die Funktionalität und muss dann nur noch eine UI davor packen.

Bei mir hat sich dieses Bewusstsein, immer vom UI aus zu arbeiten, eigentlich letztes Jahr auf der Advanced Developers Conference gefestigt. In bestimmt 4 oder 5 der von mir besuchten Sessions wurde genau dieses Vorgehen empfohlen, ebenso im anschliessenden Workshop mit Ralf Westphal. Gegenteilige Meinungen habe ich nicht mitbekommen.
Genau daran denke ich jetzt immer, wenn ich von Kollegen höre "das können wir jetzt nicht so einfach ändern, dann müsste ich das ganze Backend umstellen". Dieser Satz taucht immer auf, wenn man dem Kunden zum ersten Mal das UI vorstellt...

Grüsse,

N1ls

Wenn man erst die UI macht besteht aber die Gefahr das man u.u:

  • "mal eben" eine Funktionalität ein hackt,
  • das man Dummy Templates erstellt die die Funktionalität erst viel Später bekommen (wichtige Zeit verloren),
  • das man UnitTests weg lässt um die UI "schnell mal eben" mit Funktionalität aus zu statten,
  • das man weniger Abstrahiert sondern direkt mit der UI verknüpft (Ruf die Komponente einfach mal schnell auf()
  • und zu guter letzt das man die UI immer wieder umbauen muss da sich bei der Implementation der Funktionalität neue Erkenntnisse ergaben.

Zu beginn steht sowieso die Planung, und in der Praxis wird man vermutlich beides benutzen, eine einfache UI zur Präsentation von UX für die Kunden und/oder das C Level, und aus der Gegenrichtung komme die Implementation entgegen. Gerade wenn es in unterschiedlichen Teams gemacht wird wäre es für die Komponenten blöd wenn sie auf die Applikation warten müssten, da entwickeln sich beide entgegen und am ende handen die framework/platform group zur application group über.

Hinweis von herbivore vor 13 Jahren

Bitte keine Diskussion rein darum, ob es besser ist, Top-Down oder Bottom-Up zu entwickeln. Das Thema sind Unit-Tests.

Hallo CSL,

Wenn man erst die UI macht besteht aber die Gefahr das man u.u:

  • "mal eben" eine Funktionalität ein hackt,
  • das man UnitTests weg lässt um die UI "schnell mal eben" mit Funktionalität aus zu statten,
  • das man weniger Abstrahiert sondern direkt mit der UI verknüpft (Ruf die Komponente einfach mal schnell auf()

Da gebe ich Dir vollkommen Recht. Dazu gehört dann natürlich Disziplin und sicherlich auch Überzeugungsarbeit bei so manchem Chef, um gegen diese Gefahren zu arbeiten. Aber das ist doch auch ein Stück, worauf man hinaus will, wenn man Test-Driven entwickeln als sinnvoll ansieht, oder?
Das UI steht, es ist bekannt welche TextEdits es gibt, welche Checkboxen, Radiobuttons etc. Jetzt kann man an die Logik des UI gehen und diese Test-Driven entwickeln - quasi per Unit-Tests Stück für Stück das Klasse aufbauen, die die Logik des UI widerspiegelt.

  • das man Dummy Templates erstellt die die Funktionalität erst viel Später bekommen (wichtige Zeit verloren),

Man muss ja nicht zwangsweise das komplette UI sofort erstellen. Wenn sich Teile sinnvoll abgrenzen lassen, kann man da sicherlich schrittweise vorgehen.

  • und zu guter letzt das man die UI immer wieder umbauen muss da sich bei der Implementation der Funktionalität neue Erkenntnisse ergaben.

Genau das bezweifel ich. Das UI entwickele ich nach den Anforderungen und Wünschen des Kunden. Wenn dieser damit zufrieden ist, dann interessiert ihn nicht mehr, was dahinter liegt. Wenn bei der Implementierung der Funktionalitäten dann Probleme auftauchen, heisst das entsprechend, ich kann Anforderungen respektive Wünschen nicht mehr gerecht werden. Dann habe ich aber ein ganz anderes Problem als den Umbau des UI. Das sollte aber der Ausnahmefall sein.

Grüsse,

N1ls

Gerade ein Beispiel, warum Tests sinnvoll sind. Ist allerdings C++.

Klasse, die einen Kreisbogen repräsentiert hat Members


double minAngle;
double maxAngle;
double radius;

Es gibt eine Methode Rotate. Eine Rotation wird dabei durch eine komplexe Zahl repräsentiert (Multiplikation mit komplexer Zahl entspricht Drehstreckung).


void rotate(const complexn& p) {
    radius *= std::norm(p);
    double dAngle = std::arg(p);
    minAngle += dAngle;
    maxAngle += dAngle;
}

Hab ich beim Testen ausgelassen, ist ja offensichtlich richtig.

.
.
.
.

Und, sieht jemand den Fehler?

Die Norm einer komplexen Zahl entspricht Realteil2 + Imaginärteil2 (OHNE Wurzel). Das andere ist der Absolutbetrag. Als Studierter Mathematiker war mir diese Unterscheidung nicht bekannt und sie ist auch total Schwachsinnig, da die Norm einer komplexen Zahl dann keine Norm ist (z.B. erfüllt sie keine Dreiecksungleichung), aber ist halt so definiert und in C++ so umgesetzt.

Nachdem ich mehrere Stunden mit dem Debugger verbracht habe ist mir das erst aufgefallen, als ich systematisch auch die kleineren Methoden mit Unit Tests abgedeckt habe.

Hallo,

Die Norm einer komplexen Zahl entspricht Realteil2 + Imaginärteil2 (OHNE Wurzel).

Wenn die komplexe Zahlenebene mit der euklidischen Ebene ident ist (Normalfall) dann ist die (euklidische) Norm mit Wurzel. Euklidische Norm = Absolutbetrag = Modulus.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Wenn die komplexe Zahlenebene mit der euklidischen Ebene ident ist (Normalfall) dann ist die (euklidische) Norm mit Wurzel. Euklidische Norm = Absolutbetrag = Modulus.

Das war das, was ich bisher geglaubt habe (und eine spontane Umfrage in meiner Abteilung unter meist promovierten Mathematikern, Physikern und Informatikern auch bestätigt wurde).

Aber formal scheint es eben unterschiedlich definiert zu sein.

Einerseits
Wolfram MathWorld schreibt "Here |z|, is known as the complex modulus (or sometimes the complex norm)"

Andererseits
Wikipedia dazu: "The common terms used in the theory are chiefly due to the founders. [...] Gauss used i for Sqrt(-1) , introduced the term complex number for a + bi, and called a2 + b2 the norm."

C++-Standard dazu: "The norm value of a complex number is the squared magnitude, defined as the addition of the square of both the real part and the imaginary part (without the imaginary unit). This is the square of abs (x)."

Insofern ist die Diskussion da hinfällig (genauso wie die Frage, ob 0 nun eine natürliche Zahl ist oder nicht oder die in einem anderen Thread diskutierte frage, wie man "richtig" rundet). Es ist eher ein Beispiel, dass - nur weil man sich sicher ist, dass etwas stimmt - man es dennoch testen sollte....

Unklarheiten

Hallo zusammen,

mir scheint es so, als herrsche keine Einigkeit darüber, was unter dem Begriff TDD zu verstehen ist. Auch wie und was zu testen ist, scheint nicht klar auf der Hand zu liegen.
Was haben Entwurfsmuster für GUIs mit Software Tests zu tun? Ich kann da keine Verbindung erkennen. Oder fehlt mir da als Test-Neuling und Test-Kritiker einfach noch das entscheidende Mosaik-Steinchen?

Mir kommt das teilweise immer noch überbewertet vor. Einige hier stellen TDD über Alles (so ist das zumindest bei mir rübergekommen). So nach dem Motto: "Eine gute Architektur ergibt sich automatisch, wenn man TDD macht". Einige positive Nebeneffekte im Code durch TDD leuchten mir ja ein. Aber mit Architektur hat das nichts zu tun.

Ich würde gerne noch wissen, bei was für Arten von Projekten welcher Nutzen sich durch TDD ergeben hat?

Hat jemand von euch TDD z.B. in einem größeren plattformübergreifenden Projekt eingesetzt? Wie war da die Nutzen-Ausbeute?

Oder hat jemand ein größeres Migrationsprojekt (in Richtung .NET) mit älteren Sachen wie VB6-ActiveX-Controls, COM+, Excel-Makros, sonstigem Office-Krempel oder gar DDE-Kommunikation mit TDD abgewickelt? Ist TDD bei solchen Projekten überhaupt anwendbar? Und wenn ja, lohnt es sich auch bei solchen Projekten wirklich mit TDD zu arbeiten?

Wenn wir hier diskutieren, wie hoch der Nutzen beim Testen von Hello World-Beispielen (Kreisberechnung und so was) ist, dann ist das Kaffeesatzlesen. Wie läuft tatsächlich es in der Praxis?

Wie sieht es z.B. mit Gespeicherten Prozeduren auf dem SQL Server aus? Wie testet ihr die? Ich will jetzt nicht hören, dass man Gespeicherte Prozeduren einfach gar nicht einsetzt (Ich vermeide sie selbst, wenn irgend möglich, aber sie haben ihre Daseinsberechtigung und enthalten Geschäftslogik, die ja eigentlich getestet werden müsste).

Wenn die zu testende Software-Lösung z.B. ein Word-Vorlage mit lebenswictigen VBA-Makros enthält, wie testet Ihr sowas?

Oder eine Access-Datenbank die VBA-Code enthält? Da ist nix mit automatischen Builds, etc. Hilft die TDD-Lehre einem bei sowas weiter?

Oder gibt es vielleicht bestimmte Konstrukte innerhalb einer Software-Lösung, die man doch besser vom Testen ausklammert?

Hallo Rainbird,

was unter dem Begriff TDD zu verstehen ist.

Kurz und grob: Den Test vor der Implementierung schreiben.
Zusammengefasst kannst du das auch in Test-driven development nachlesen. MMn herrscht schon Enigkeit was unter dem Begriff verstanden wird. Die Umsetzung dessen ist jedoch eine andere Frage. Vielleicht hilft dir Code Contracts By Example ein wenig weiter.

Was haben Entwurfsmuster für GUIs mit Software Tests zu tun?

Wenn es nach Martin Fowler geht dann wurde MVP und dessen Abwandlungen ja nur deshalb entwickelt um "es" testbar zu machen. ZB indem sämtliche Logik von der GUI entfernt und in den Presenter verschoben wird kann dieser automatisch getestet werden - ohne dass ein Benutzer auf die Buttons klicken muss. Das "automatisch" ist dabei ein wichtiger Punkt. Ist es dir klarer geworden oder soll weiter ausgeholt werden?

Eine gute Architektur ergibt sich automatisch, wenn man TDD macht

Stimmt auch 😁
Im Ernst: Wenn die Klassen - oder besser die Schnittstellen - so entworfen werden dass "sie" testbar sind dann werden viele der OO-Prinzipien automatisch angewandt. Testbarmachen fördert zB DI und SoC - sonst sind Tests kaum möglich.
Wird TDD angewandt ergibt sich hier auch der Vorteil dass von vorn herein die Schnittstellen entsprechend entworfen werden. Werden die Test nachher geschrieben kann es leicht passieren dass nicht alles so testbar ist wie es sein sollte.

bei was für Arten von Projekten welcher Nutzen sich durch TDD ergeben hat?

Der Nutzen der sich für mich ergibt ist dass der Code getestet ist und somit entsprechend Spezifikation fehlerfrei ist. Das ist doch was?!
Ich würde mir gar keine größeres Projekt angehen zu trauen wenn ich nicht weiß dass das "Fundament" getestet ist - sonst könnte es dann beim "Dach" gewaltig krachen.
Ein weiterer Nutzen ist - wenn du dir Test als Sicherheitsnetz vorstellst - dass dieses Netz mit jedem gefunden Bug im Release dichter wird (bis es theoretisch nach t -> Inf ganz dicht ist 😉
Oder wenn du etwas am bestehenden Code änderst (zB Refactoring) kann mit den sichergestellt werden dass sich kein unerwünschter Nebeneffekt eingeschlichen hat wenn alle Tests bestanden werden.

Zur Frage nach welchem Projekttyp: Bei mir alle außer die du aufgezählt hast 😉 Bei diesen hab ich keine Erfahrung da nicht zutreffend und insofern kann ich nichts dazu sagen.

größeren plattformübergreifenden Projekt

Was meinst du damit? Speziell auf was beziehst du "plattformübergreifen"?

Wenn wir hier diskutieren, wie hoch der Nutzen beim Testen von Hello World-Beispielen (Kreisberechnung und so was) ist, dann ist das Kaffeesatzlesen. Wie läuft tatsächlich es in der Praxis?

Unit-Testen heißt kleine spezifische Funktionalitäten im Code testen (~Methoden). Wenn die zu testende Software gut erstellt ist - gut heißt hier testbar - dann ergeben sich mehr oder weniger nur "Hello World Beispiel" und diese sind halt leich testbar. Ein Monolith ist nur sehr schwer testbar und sollte auch refactored werden 😉
Insofern verstehe ich den Einwand mit "Kaffeesatzlesen" nicht denn der Großteil her hier diskutierten Beispiel (sofern ich sie verfolgt habe) entsprechen der Praxis.

Wie sieht es z.B. mit Gespeicherten Prozeduren auf dem SQL Server aus?

Können mit VS 2010 getestet werden. Siehe How to unit test SQL Server 2008 database using Visual Studio 2010 ff.

Da ist nix mit automatischen Builds, etc. Hilft die TDD-Lehre einem bei sowas weiter?

Das hab ich jetzt zwar aus dem Zusammenhang gerissen aber automatische Builds sind keine Voraussetzung für Unit-Tests oder TDD.

Oder gibt es vielleicht bestimmte Konstrukte innerhalb einer Software-Lösung, die man doch besser vom Testen ausklammert?


public int ID { get; set; }

braucht nicht getestet werden 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Hallo Rainbird,

warum stellst du jetzt die ganzen Fragen neu, die alle schon beantwortet wurden?

Der Thread ist echt schon lang genug. Soll das jetzt alles wieder von neuem begonnen werden? Eine neue Runde, bei der alles nochmal neu durchgekaut wird? Bitte nicht!

Ich weiß, jetzt fragst du nach TDD, am Anfang hast du nach Unit Tests gefragt. Aber die Diskussion hatte sich ja schon lange in Richtung TDD entwickelt und daher ist m.E. auch zu TDD alles gesagt.

Ich denke auch nicht, dass eine neue Diskussion für dich persönlich was bringt. Du warst bei Unit Tests ablehnen skeptisch und bist es offensichtlich geblieben. Ich sehe keinen Grund, warum das bei TTD anders laufen sollte. Offensichtlich hast du eine grundsätzliche Abneigung, die sachlichen Argumenten anscheinend schwer zugänglich ist.

Versteh mich nicht falsch. Deine Qualifikation steht außer Frage und ich will die nicht anzweifeln. Ich möchte nur verhindern, dass das hier endlos geht, wo schon alles Wesentliche gesagt wurde. Es wäre schade, wenn ein wertvoller Thread durch seine schiere Länge so unattraktiv wird, dass er seinen Nutzen verliert.

Ich würde mich freuen, wenn wir es bei gfoidl Zusammenfassung belassen könnten. Das wäre doch ein nettes Schlusswort.

herbivore

Information von herbivore vor 13 Jahren

Bitte wiederholt nichts, was schon besprochen wurde. Lest also vor einer Antwort bitte den Thread genau durch und fangt nicht einfach bei Null an alles wieder von vorne zu wiederholen. Wir behalten uns vor, redundante Beiträge zu entfernen.

Hallo herbivore,

Ich denke auch nicht, dass eine neue Diskussion für dich persönlich was bringt.

Wenn ich darüber nachdenke, hast Du damit nicht ganz unrecht.
Die Diskussion hat ihr mögliches geleistet, der Rest kann nur durch Ausprobieren in der Praxis geschafft werden. Bevor ich es nicht selber in einem abgesteckten Projekt ausprobiert habe, werde ich vermutlich immer daran herumnörgeln.

Also möchte ich gfoidls Schlußwort gerne so stehen lassen.