Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Tatsächlicher Nutzen von Unit-Tests [und TDD]
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 2.891

beantworten | zitieren | melden

Zitat von CSL
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.
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

Zitat von Golo Roden
...
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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von userid14268 am .
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

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 ...
Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von Golo Roden am .
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
zero_x
myCSharp.de - Member

Avatar #avatar-2567.gif


Dabei seit:
Beiträge: 1.044
Herkunft: Koblenz

beantworten | zitieren | melden

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
zero_x | myCSharp.de - gemeinsam mehr erreichen

Für längere Zeit inaktiv.
private Nachricht | Beiträge des Benutzers
Peter Bucher
myCSharp.de - Experte

Avatar #jVxXe7MDBPAimxdX3em3.jpg


Dabei seit:
Beiträge: 5.940
Herkunft: Zentralschweiz

beantworten | zitieren | melden

Hallo CSL

Ich bin zwar Schweizer, aber nicht in allen Belangen neutral ;)
Zitat von CSL
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?
Zitat von CSL
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.
Zitat von CSL
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

- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Peter Bucher
myCSharp.de - Experte

Avatar #jVxXe7MDBPAimxdX3em3.jpg


Dabei seit:
Beiträge: 5.940
Herkunft: Zentralschweiz

beantworten | zitieren | melden

@CSL [ ] Du hast verstanden, worum es geht.
--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
private Nachricht | Beiträge des Benutzers
N1ls
myCSharp.de - Member



Dabei seit:
Beiträge: 46

beantworten | zitieren | melden

Hallo zusammen,

interessante Diskussion, ich klink mich mal ein ;-)
Zitat von 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.
Zitat von CSL
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 ;-)
Zitat von Golo Roden
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:
Zitat von CSL
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
private Nachricht | Beiträge des Benutzers
zero_x
myCSharp.de - Member

Avatar #avatar-2567.gif


Dabei seit:
Beiträge: 1.044
Herkunft: Koblenz

beantworten | zitieren | melden

Hallo CSL,
Zitat von 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
zero_x | myCSharp.de - gemeinsam mehr erreichen

Für längere Zeit inaktiv.
private Nachricht | Beiträge des Benutzers
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 742

beantworten | zitieren | melden

@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.
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

Oh. Es gab ja noch antworten, gar nicht gesehen :D
Zitat von N1ls
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 :D

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 :)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von userid14268 am .
private Nachricht | Beiträge des Benutzers
koller
myCSharp.de - Member



Dabei seit:
Beiträge: 142

beantworten | zitieren | melden

Hallo,

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


Grüße, Koller.
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

Zitat von koller
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
private Nachricht | Beiträge des Benutzers
koller
myCSharp.de - Member



Dabei seit:
Beiträge: 142

beantworten | zitieren | melden

Hallo,

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

Grüße, Koller.
private Nachricht | Beiträge des Benutzers
aequitas
myCSharp.de - Member

Avatar #avatar-3079.png


Dabei seit:
Beiträge: 458
Herkunft: Unterfranken

beantworten | zitieren | melden

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!
private Nachricht | Beiträge des Benutzers

Moderationshinweis von gfoidl (25.08.2010 - 13:02)

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

xxxprod
myCSharp.de - Experte

Avatar #avatar-2329.gif


Dabei seit:
Beiträge: 1.378
Herkunft: Österreich\Wien

beantworten | zitieren | melden

[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
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 9.972

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
N1ls
myCSharp.de - Member



Dabei seit:
Beiträge: 46

beantworten | zitieren | melden

Zitat von CSL
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.
Zitat von CSL
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.
Zitat
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
private Nachricht | Beiträge des Benutzers

Moderationshinweis von herbivore (26.08.2010 - 08:19)

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.

userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

Zitat von N1ls
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.
Zitat von N1ls
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.
Zitat von N1ls
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.
Zitat von N1ls
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.
Zitat von N1ls
Zitat von CSL
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.
Zitat von N1ls
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
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo N1ls,
Zitat
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
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
N1ls
myCSharp.de - Member



Dabei seit:
Beiträge: 46

beantworten | zitieren | melden

Hallo herbivore,
Zitat von herbivore
Zitat
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.
Zitat
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
Zitat
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
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers

Moderationshinweis von herbivore (26.08.2010 - 21:47)

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

N1ls
myCSharp.de - Member



Dabei seit:
Beiträge: 46

beantworten | zitieren | melden

Hallo CSL,
Zitat von 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.
Zitat
- 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.
Zitat
- 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
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1.578

beantworten | zitieren | melden

Zum Thema Button-Up Top-Down: Entwickelt ihr eurere Applikationen lieber Top-Down oder Bottom-Up?
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

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 Realteil^2 + Imaginärteil^2 (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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Uwe81 am .
private Nachricht | Beiträge des Benutzers