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]
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,

wenn eine Methode verschiedene Aspekte einer XML-Datei überprüft, dann finde ich es vollkommen gerechtfertigt, wenn es da viele Stellen gibt, die eine Exception werfen. Dass es diese vielen Stellen gibt, ist kein Argument für eine Aufteilung.

Aber selbst wenn man die einzelnen Prüfungen in einzelne Methoden packen würden, bräuchte man sinnvollerweise eine Methode, die die ganzen Prüfungen hintereinander aufruft. Und diese Methode würde dann (indirekt) 15 Exceptions werfen können. Man hätte also nichts gewonnen.

Davon abgesehen geht dein Einwand an dem eigentlichen Punkt voll vorbei. Hier ging es ja darum, ob private Methoden getestet werden sollen oder müssen. spike24 hat argumentiert, dass man private Methoden normalerweise nicht testen muss. Sein Beispiel hat er als Ausnahme von dieser Regel angeführt. Und diese basiert darauf, dass die private Funktionalität an verschiedenen Stellen benutzt wurde. Das wäre aber auch nach einer Aufteilung in viele kleine (natürlich ebenfalls private) Methoden so. Eine etwaige Aufteilung ändert also überhaupt nichts an dem eigentlich zur Diskussion stehenden Punkt.

herbivore
private Nachricht | Beiträge des Benutzers
spike24
myCSharp.de - Member



Dabei seit:
Beiträge: 451
Herkunft: Steiermark Österreich

beantworten | zitieren | melden

@FZelle
Es ist eh nicht eine einzelne Methode, weis es zwar nicht mehr genau, aber soweit ich mich errinnern kann gibt es für jeden NodeType in dem XML eine eigene Methode. oder so ähnlich. Eine Methode alleine hätte den Review eh nicht geschafft.

[offtopic]
Kann es sein, dass es Dich gibt seit dem ich programmiere?
[/offtopic]
mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Nein, ich bin schon älter ;-)
aber wir kennen uns aus nem anderen Forum, sozusagen aus nem anderen Leben.


@herbivore:
Zitat
Davon abgesehen geht dein Einwand an dem eigentlichen Punkt voll vorbei. Hier ging es ja darum, ob private Methoden getestet werden sollen oder müssen.
Dann habe ich mich etwas missverständlich ausgedrückt.
Ich persönlich halte nichts von Tests für internal oder private, denn private und internal bedeuten das es sich jederzeit ändern kann, denn es ist kein Bestandteil des Kontraktes dieser Klasse.

Aber wenn etwas so wichtig ist, das man meint es testen zu müssen, dann ist es automatisch falsch als privat oder internal deklariert.

Und das ist eben einer der Aspekte von TDD, man sieht beim Erstellen des Kontraktes ( denn der kommt zuerst ) was zu testen ist, und alles was zu testen ist ist eben öffentlich.

Und was nicht öffentlich ist, braucht auch nicht getestet werden.

Und zu Spikes beispiel, das sehe ich anders.
Wenn eine Routine so gross wird, hat man wahrscheinlich einiges beim Design nicht beachtet.
Gerade bei XmlParsern kann man durch vernünftige Pattern Ausnutzung sehr häufig den Code drastisch verkleinern.
Aber das kann man nur konkret machen, nicht pauschal oder abstrakt.
private Nachricht | Beiträge des Benutzers
Stefan O.
myCSharp.de - Member



Dabei seit:
Beiträge: 72
Herkunft: Bergisch Gladbach

beantworten | zitieren | melden

Zitat von FZelle
(...)
Aber wenn etwas so wichtig ist, das man meint es testen zu müssen, dann ist es automatisch falsch als privat oder internal deklariert.

Und das ist eben einer der Aspekte von TDD, man sieht beim Erstellen des Kontraktes ( denn der kommt zuerst ) was zu testen ist, und alles was zu testen ist ist eben öffentlich.

Und was nicht öffentlich ist, braucht auch nicht getestet werden.
(...)

Hallo FZelle,

deine Aussage würde aber bedeuten, das Hilfsklassen einer Assembly, welche internal sind, nie getestet werden. Oder würdest du diese auch implizit durch die öffentlichen Kontrakte mittesten?
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Unittests sind u.a. dazu da agiles entwickeln zu erleichtern.

Bei den agilen Methoden geht es u.a. darum, nur das zu implementieren, was der Kunde gerade wirklich braucht/bestellt hat und wenn sich die Vorgaben und Ziele ändern den Code "gefahrlos" refaktorieren zu können.
Dann helfen Unittests das zumindest der Teil der schon funktionierte nicht zerstört wird, oder es zumindest gleich erkannt wird.

Bei vernünftiger Architektur muss man davon ausgehen das alles was Public
ist, als Kontrakt für andere gedacht ist.
Wenn man also Klassen designed wird man sich ja etwas dabei denken, wenn man etwas als Private deklariert.
Diese Teile der SW sind also von vornherein als nicht von aussen benutzbar bzw. als volatile gedacht.
Sie sind also explizit dafür gedacht ggf bei refactorings "geopfert" zu werden.
Internal ist etwas anderes, denn es ist innerhalb einer Assembly ja wie Public anzusehen und stellt intern also eigentlich einen Öffentlichen Kontrakt da.
Diese Klassen sollten dann schon getestet werden.
Allerdings ist Internal wohl ähnlich wie Singleton eine meist missbrauchte Sache.

Gehen wir mal davon aus du hast für alles und jedes in deinem Projekt Unittests gemacht, also auch für jede Private Funktion.
Jetzt wird von 2 Tier auf 3 Tier erweitert, weil der Kunde mit mal Konzern wird.
Jetzt musst du eigentlich ziemlich viel refaktorieren, weil sich der Businesslayer von
einem internen, auf z.b. einen Appserver ändert.
Wenn du jetzt aber alle deine (privaten) Unittests wegschmeissen kannst, und für die neuen Privat Funktionen neue machen musst, wird bei den meisten Entwicklern dann irgendwann eine der folgenden Sachen passieren:

1. Es wird nicht mehr vernünftig refactoriert, weil das ja die tests zerstört, also wird ggf zu viel drumherumgefrickelt statt konsequent sachen wegzuwerfen oder

2. Die Leute haben die schn.. voll von Unittests weil ja ständig was kaputt geht und immer wieder alles doppelt gemacht werden muss, also werden irgendwann gar keine mehr gemacht.

Also ja, ich würde nur öffentliches Testen, dabei werden diese Internas ja automatisch getestet.
Und ist etwas so wichtig, das es einzeln getestet werden muss, stellt es ja eigentlich einen öffentlichen Kontrakt da, und dann sollte er auch nicht private sein.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,
Zitat
Und was nicht öffentlich ist, braucht auch nicht getestet werden.
darin sind sich ja du, spike24 und ich von Grundsatz her einig. Auch über den Zweck und Nutzen dieser Regel. Ich finde jedoch, dass das Beispiel von spike24 zeigt, dass es (wenige) bestimmte Fällen geben kann, wo es sinnvoll ist, von diesem Grundsatz abzuweichen.

herbivore
private Nachricht | Beiträge des Benutzers
spike24
myCSharp.de - Member



Dabei seit:
Beiträge: 451
Herkunft: Steiermark Österreich

beantworten | zitieren | melden

[offtopic]
aus einer anderen Welt ist gut
[/offtopic]

Wie herbivore sagt, bin ich auch der Meinung dass man nur öffentliches testen muss (soll?)
Wenn ich in einer Assembly nur eine Klasse habe die public ist, ist sicherzustellen dass diese ihr Verhalten nicht ändert.

Bei meinem Projekt (ORMapper) teste ich "momentan" nur klassen die ein öffentliches Interface impelementieren ... eigentlich könnte ich alle anderen klassen dann internal machen aber das ist ein anderes Thema.
ein Interface ist IConnector
und beim testen ist es mir eigentlich komplett egal woher er die daten bekommt, aus der lokalen Access datenbank oder über csv aus China und welche klassen er dafür braucht. Bei der Verwendung muss ein richtiges DataTable rauskommen.
Also privates zu testen ist vielleicht nicht sinnlos aber zuviel und unötig

In meinem Beispiel ist es eigentlich nur deswegen sinnvoll da ich sonst die doppelte Anzahl von tests gehabt hätte und ich im endeffekt zu faul war diese zu schreiben, bzw. wenn sich das XML ändert diese zu warten.
sonst halte ich auch nicht sonderlich viel davon. Ich würde mich bei einer zentralen internal Klasse vielleicht noch breitschlagen lassen wenn diese von vielen Stellen benützt wird. Aber da auch nur die Fehlerfälle damit ich diese Tests nicht bei allen x public klassen schreiben muss (d.h. Testanzahl verringern)

//Edit
@Stefan O.
Wenn private und/oder internal klassen nicht durch das testen der öffentlichen Klasse verwendet werden ... wann werden die denn sonst verwendet?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von spike24 am .
mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen
private Nachricht | Beiträge des Benutzers
Stefan O.
myCSharp.de - Member



Dabei seit:
Beiträge: 72
Herkunft: Bergisch Gladbach

beantworten | zitieren | melden

@ FZelle

Danke für die ausführliche Erläuterung.
Ich versuche derzeit für mich selbst abzuklären ob es sinnvoll ist private zu testen.
Zum Beispiel wurde im "Lernen von anderen" Artikel der dotNetPro 01/2010 auch private bzw. internal getestet.

Aber ich denke auch, dass das Testen von privaten Methoden "unsinnig" ist.

@spike24

Da musst du mich missverstanden haben. Natürlich sollte es private/internal Klassen nur geben wenn Sie auch verwendet werden. Ansonsten sind sie "müll".
private Nachricht | Beiträge des Benutzers
userid14268
myCSharp.de - Member



Dabei seit:
Beiträge: 1620

beantworten | zitieren | melden

BTW, man kann in VS auch privates testen ohne sie internal machen zu müssen, dafür gibt es den accessor.
Internal verwende ich fast nie

Aber ihr meint im Prinzip das ist, wenn ich pauschal alle Methoden teste, etwas über das Ziel hinaus schieße?

Die Code Coverage Results von VS monieren auch die Privaten Methoden als "nicht getestet" :-/

Sind denn nicht die einzelnen Zwischenschritte der Privaten Methoden nicht einfacher zu verifizieren?

Wenn ich eine Methode in einer "Controller" Klasse habe, die ruft intern weitere Klassen und Aktionen auf, dann kann ich dort beim verifizieren viel schneller kleine Sachen übersehen die ich abfangen würde hätte ich die zwischen Methoden getestet.
Und nein, der Controller ist keine Monsterklasse, der ist nur der Einstiegspunkt um eine komplexe Aktion zu starten und zu steuern, einer muss das ja tun.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von userid14268 am .
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo CSL,

gerade mit Blick auf den Nutzen von Unit-Tests beim Refactoring ist es kontraproduktiv, private Methoden direkt zu testen, statt nur indirekt über öffentliche Methoden, weil du dann nach einer Änderung der Implementierung die Tests nicht einfach unverändert laufen lassen kannst, um eine verlässliche Aussage über die Korrektheit der Änderungen zu bekommen, sondern die Tests erst anpassen musst.

Das bedeutet nicht nur zusätzlichen Aufwand, sondern nach der Anpassung der Test ist Qualität der Aussage über die Korrektheit nicht so gut, wie bei unveränderten Tests, denn bei der Anpassung des Tests können sich ja neue Fehler eingeschlichen haben.

herbivore
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Stellt Euch vor, ihr habt eine WCF Schnittstelle die ein dutzend Methoden zur Verfügung stellt. Bei jedem Aufruf einer Methode auf der Schnittstelle können dutzende verschiedener Exceptions auftreten. Jede der Exception soll anders behandelt werden (benutzerfreundlicher und passender Text und verpacken in eigene Exception und throw). Wie testet Ihr so was? Wenn Ihr das nur auf dem Interface der Komponente testet welche die WCF-Kommunikation kapselt, dann habt ihr allein für das Fehlerhandling deutlich über 100 Tests. Und es sind immer genau dieselben Tests! Wäre es denn nicht einfacher einen ExceptionCatcher wie folgt zu bauen:


private T ExceptionCatcher<T>(Func<T> function)
{
	try
	{
		return function();
	}
	catch (ArgumentNullException ex)
	{
		throw new IrgendwasException("parameter war null", ex);
	}
	catch (Exception ex)
	{
		throw new IrgendwasException("unbekannter fehler", ex);
	}
}

Diesen dann vollständig zu testen (der gehört ganz sicher nicht zu einem Kontrakt) und dann immer nur noch (z.B. mit Rhino.Mocks) zu prüfen, ob die Methode bei jeder Operation auf der WCF-Schnittstelle auch wirklich aufgerufen wird.


public bool IsEqual(string irgendwas)
{
	return ExceptionCatcher(() => TryIsEqual(irgendwas));
}
Das reduziert die Tests um einen erheblichen Faktor und die Wahrscheinlichkeit dass Testfälle fehlen oder falsch getestet wird nimmt entsprechend ab.
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Dann ist aber ExceptionCatcher aber nicht Bestandteil der Implementierung sondern eine Hilfsklasse für die Tests und gehört in die Unittest Klasse.
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Zitat von FZelle
Dann ist aber ExceptionCatcher aber nicht Bestandteil der Implementierung sondern eine Hilfsklasse für die Tests und gehört in die Unittest Klasse.

?( ?( ?( ?( Wie kommst Du denn darauf??
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,
Zitat
Dann ist aber ExceptionCatcher aber nicht Bestandteil der Implementierung sondern eine Hilfsklasse für die Tests und gehört in die Unittest Klasse.
der ExceptionCatcher wäre zwar eine Hilfsklasse, aber keine Hilfsklasse für die Tests sondern eine Hilfsklasse für das Modell. Insofern gehört er auf keinen Fall in die Unittest Klasse.


Hallo SeboStone,

wie schon gesagt, gibt es bestimmte Ausnahmen, bei denen es sinnvoll ist, Tests für private Methoden bzw. Klassen zu schreiben. Was du beschreibst klingt danach, als würde es so eine Ausnahme sein.

herbivore
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Zitat
Und es sind immer genau dieselben Tests! Wäre es denn nicht einfacher einen ExceptionCatcher wie folgt zu bauen:
Das heisst für mich, hier wird eine Funktion gebaut, die für das Testen gedacht ist, also ist es ein TestHelper.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,

nein, das hast du missverstanden. Die Klasse ExceptionCatcher ist dafür da, um die Implementierung zu vereinfachen, nicht den Test. Das geht aber aus dem Post von SeboStone ziemlich klar hervor.

herbivore
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Denke ich nicht.

Wenn er explizit schreibt das es immer die selben Tests sind und daraufhin vorschlägt einen ExceptionCatcher zu schreiben, dann bleibt keine andere Wahl das so zu interpretieren.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,

du hast dir den ExceptionCatcher aber schon angeschaut und die Beschreibung was er tun soll? Das ist eindeutig Businesslogik. Im Prinzip wird hier ein Aspekt, nämlich das an verschiedenen Stellen immer gleich Exeption-Handling, ausgelagert. Das reduziert die Redundanz der Modellklasse. Den ExceptionCatcher wäre also auch dann sinnvoll, wenn man überhaupt keine Unit-Tests schreiben würden.

Die Testbarkeit erhöht sich nur wegen der Reduzierung die Redundanz.

Dass diese Verbesserung der Architektur durch Überlegungen zum Test ausgelöst wurde, deckt sich ja voll mit dem, was du oben gesagt hast:
Zitat
TDD ist nicht nur Selbstzweck, sondern soll einem auch die Augen öffnen ...

Aber nur weil eine Änderung durch den Test motiviert wurde, heißt das ja noch lange nicht, dass die entstandene Klasse ExceptionCatcher in den Test-Code gehört. Und das tut sie eben auch nicht. Ob du das nun einsiehst oder auch nicht.

herbivore
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Das hat mit einsehen nichts zu tun.
Natürlich könnte dies tatsächlich so gedacht gewesen sein, aber es steht so nicht da.

Und selbst wenn, hat dann eine so wichtige Funktion ( sie wird dann ja dreh und Angelpunkt für jeden Funktionsaufruf ) nicht private zu sein, denn sie wird durch ihre Wichtigkeit automatisch zu einer nicht änderbaren und damit öffentlichen Funktion.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo FZelle,

dass eine private Methode oder Klasse häufig benutzt wird und wichtig ist, sogar so wichtig, dass sie als nicht änderbar angesehen wird, heißt doch noch lange nicht, dass sie öffentlich gemacht werden muss oder auch nur darf. Das ist doch abstrus. Damit vermischt du völlig unterschiedliche Konzepte: Wichtigkeit für die Implementierung auf der eine Seite und öffentliches Verhalten eines Objekts. Ich kann mich des Eindrucks nicht erwehren, du hast dich bei dem konkreten Fall ziemlich verrannt.

herbivore
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


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

beantworten | zitieren | melden

herbivore,

ich muss an dieser Stelle FZelle zur Seite stehen - ich sehe das genauso wie er. AUch für mich ist das keine Businesslogik, und gehört zu den Tests - schließlich wird es ja auch nur für die Tests erstellt und ist Hilfslogik für die Tests.

Und woher Du weißt, ob etwas missverstanden wurde, ist mit schleierhaft - ich denke, das kann nur SeboStone beantworten.

Und gleich von verrannt zu sprechen, halte ich für etwas ... Fehl am Platze, um es mal vorsichtig auszudrücken.

Viele Grüße,


Golo
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
spike24
myCSharp.de - Member



Dabei seit:
Beiträge: 451
Herkunft: Steiermark Österreich

beantworten | zitieren | melden

Mir ist es ziemlich egal wer wohin rennt, solange ich nicht nachrennen muss.
(Für die Frauen unter uns: euch schon garnicht)
Zitat
automatisch zu einer nicht änderbaren und damit öffentlichen Funktion
öffentlich im Sinnen von public class oder im Sinne von hervorgehoben und gut dokumentiert aber internal class?
mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Golo Roden,
Zitat
schließlich wird es ja auch nur für die Tests erstellt und ist Hilfslogik für die Tests.
nein, das stimmt beides nicht. Ich habe schon beschrieben warum.
Zitat
ich denke, das kann nur SeboStone beantworten.
Richtig, und das hat er im Prinzip auch getan, indem er seine große Verwunderung und sein Unverständnis über die Behauptung, dass die Klasse in den Test-Code gehört, zum Ausdruck gebracht hat.
Zitat
Und woher Du weißt, ob etwas missverstanden wurde, ist mit schleierhaft
Irgendwer muss es missverstanden haben, da es widersprüchliche Auffassungen gibt, wozu die Klasse dient.
Zitat
Und gleich von verrannt zu sprechen, halte ich für etwas ... Fehl am Platze, um es mal vorsichtig auszudrücken.
Das bezog sich gar nicht auf das Missverständnis, sondern auf den in meinen Augen verzweifelten Versuch von FZelle, die Absolutheit der Regel, dass nur öffentliche Methoden getestet werden dürfen, trotz plausibler Gegenbeispiele aufrechtzuerhalten.

herbivore
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Zitat von herbivore
dass eine private Methode oder Klasse häufig benutzt wird und wichtig ist, sogar so wichtig, dass sie als nicht änderbar angesehen wird, heißt doch noch lange nicht, dass sie öffentlich gemacht werden muss oder auch nur darf. Das ist doch abstrus.

Dem stimme ich absolut zu. Wie kommt man auf die Idee Methoden-Zugriffsmodifizierer nach Wichtigkeit zu vergeben? Warum nicht gleich Zugriffsmodifizierer mit der Schrotflinte reinrotzen?

Aber damit erklärt sich auch die Haltung nur Public Methods zu testen. Offensichtlich werden einfach alle Funktionen die es Wert sind getestet zu werden Public gemacht. Das ist ganz sicher der falsche Ansatz.
Zitat von herbivore
Zitat
ich denke, das kann nur SeboStone beantworten.
Richtig, und das hat er im Prinzip auch getan, indem er seine große Verwunderung und sein Unverständnis über die Behauptung, dass die Klasse in den Test-Code gehört, zum Ausdruck gebracht hat.

Tatsächlich habe ich das getan. Herbivore hat mich richtig verstanden, Golo und FZelle leider nicht. Die Klasse / Komponente braucht ein entsprechendes Exceptionhandling und nicht der Test!
Ich gebe aber FZelle recht, wenn er sagt, dass man das auch in Tests verwenden kann. Ich bezweifle dann aber stark, dass die Tests leicht nachvollziehbar und selbsterklärend sind. So ist es auch kein Wunder warum er propagiert nur Integrationstests auf den Interfaces zu bauen.

Hoffentlich habe ich mich jetzt nicht schon wieder uneindeutig ausgedrückt.
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Das hatte hier weniger etwas mit falsch verstanden zu tun:

"Ehefrau zum Ehemann:
Geh mal schnell in den Laden um die Ecke hol mal ein Brot, und wenn sie frische Tomaten haben, bring 6 mit."
Er brachte 6 Brote, und hatte vollkommen recht.

Genauso ist dein Satz oben.
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Ahh, dann bist Du also ein Till Eulenspiegel. Also wolltest Du mich nicht richtig verstehen, ist auch ok.
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10083

beantworten | zitieren | melden

Nein, das hat nichts mit verstehen wollen zu tun.
Du hast jetzt den Sinn meiner Analogie falsch interpretiert, weil du versuchst etwas "hineinzuinterpretieren".

Und genauso ist es beim Eheman.
Wenn du den Satz mal auseinander nimmst, ist es genauso wie er es verstanden hat richtig. Er hat nicht versucht das irgendwie zu interpretieren, sondern exakt so zu machen wie es ihm gesagt wurde.


Ich habe in 25 Jahren SW Entwicklung gelernt mit Sprache sehr präzise umgehen zu müssen.
Wenn man z.b. mal individual SW für eine Anwaltskanzlei macht, und auch sein Geld haben will, muss man seeeehr präzise sein.
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Zitat von FZelle
Ich habe in 25 Jahren SW Entwicklung gelernt mit Sprache sehr präzise umgehen zu müssen.
Wenn man z.b. mal individual SW für eine Anwaltskanzlei macht, und auch sein Geld haben will, muss man seeeehr präzise sein.
Dem stimme ich zu und ich bin der Meinung, dass ich mich fast immer entsprechend ausdrücke. Deswegen benenne ich auch immer wieder den Unterschied zwischen Unit- und Integrationstest - was Du z.B. nicht tust.
Vielleicht ist es mir bei dem betreffenden Post nicht ganz so gut gelungen wie gewollt, aber dann kann man doch davon ausgehen, dass ein intelligenter Leser das naheliegensde erkennt. Deine Analogie passt hierbei auch ins Bild. Wie wahrscheinlich ist es dass die Ehefrau gemeint hat dass er 6 Brote mitbringen soll?
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


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

beantworten | zitieren | melden

Zitat von herbivore
Zitat
schließlich wird es ja auch nur für die Tests erstellt und ist Hilfslogik für die Tests.
nein, das stimmt beides nicht. Ich habe schon beschrieben warum.

Sorry, herbivore, Du hast => DEINE ≤ Sicht beschrieben, warum. Die ist doch nicht allgemein gültig?
Zitat von herbivore
Zitat
Und gleich von verrannt zu sprechen, halte ich für etwas ... Fehl am Platze, um es mal vorsichtig auszudrücken.
Das bezog sich gar nicht auf das Missverständnis, sondern auf den in meinen Augen verzweifelten Versuch von FZelle, die Absolutheit der Regel, dass nur öffentliche Methoden getestet werden dürfen, trotz plausibler Gegenbeispiele aufrechtzuerhalten.

Mich hat hauptsächlich die Formulierung "verrannt" gewundert. Das klingt so ... absolutistisch, als ob FZelle ein Fanatiker wäre, der seine (in Deinen Augen) falsche Meinung auf Biegen und Brechen durchboxen muss. Das Wort "verzweifelt" geht in die gleiche Richtung.

Wie gesagt, mich wundern die Formulierungen ein wenig ...

Im Übrigen: Ich halte es nach wie vor für Blödsinn, privaten Code zu testen. Aus verschiedenen Gründen. Die genannten Beispiele (wieso eigentlich Beispiele? Es war doch nur eins?) haben mich nicht wirklich überzeugt.

Du hast selbst doch geschrieben, dass diese Helper-Klasse allgemein sein könnte:
Zitat
Im Prinzip wird hier ein Aspekt, nämlich das an verschiedenen Stellen immer gleich Exeption-Handling, ausgelagert. Das reduziert die Redundanz der Modellklasse. Den ExceptionCatcher wäre also auch dann sinnvoll, wenn man überhaupt keine Unit-Tests schreiben würden.

Einen besseren "Beweis" als diesen kann es doch kaum geben, dass es eben nicht private zu sein hat - eben WEIL es an noch mehr Stellen Sinn machen würde.
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
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Zitat von Golo Roden
Zitat
Im Prinzip wird hier ein Aspekt, nämlich das an verschiedenen Stellen immer gleich Exeption-Handling, ausgelagert. Das reduziert die Redundanz der Modellklasse. Den ExceptionCatcher wäre also auch dann sinnvoll, wenn man überhaupt keine Unit-Tests schreiben würden.

Einen besseren "Beweis" als diesen kann es doch kaum geben, dass es eben nicht private zu sein hat - eben WEIL es an noch mehr Stellen Sinn machen würde.

Was für ein Beweis? Schau Dir den ExceptionCatcher doch mal an, der wirft eine spezielle Exception, eine Komponenten-Exception. (Ok, das "Irgendwas" sieht wohl nicht danach aus, war aber so gemeint) Keine andere Komponente hat diesen ExceptionCatcher zu verwenden, denn normalerweise treten in jeder Komponente auch andere Exceptions auf. Und komponentenintern wird er auch nur an den Schnittstellen verwendet -> im Normalfall repräsentiert die Schnittstelle genau eine Klasse, im schlimmsten Fall gibts da noch eine Base-Klasse. Ergo, den ExceptionCatcher global zu machen oder sogar in den Kontrakt aufzunehmen ist ein architektonischer Gau.
private Nachricht | Beiträge des Benutzers