Aber zur Lokalisierung von Fehlern wäre es ja doch einfacher, wenn man gleich weiß, wos kracht als wenn man in der Public-Methode dann erst debuggen muss, bei welcher Aktion es denn nun warum genau kracht?
Wenn man eine Methode indirekt testet, bekommt man Fehler aus dieser Methode auch nur indirekt mit - das stimmt. Dagegen hilft aber nur Implementierungs-orientiertes testen.
Ginge ja auch in Richtung möglichst hoher Code Coverage vom Test, oder?
Code Coverage ist höchstens ein Tool um festzustellen, dass man zu wenig Tests hat. Es ist nicht geeignet zu begründen, man hätte ausreichend oder gar gute Tests.
Zitat:
An sich habt ihr schon recht: durch das Testen der public Methoden wird implizit auch der Rest getestet.
Das gilt aber nur für Klassen, die einfache Aktionen machen. Wenn die Klasse Unstetigkeiten bei besonderen Konstellationen der Daten hat, kann man das meist nur bei den privaten Methoden abtesten.
Alternativ:
- Klasse aufteilen, dass sie einfachere Aktionen durchführt
- Besondere Konstellationen durch entsprechende Methodenaufrufe produzieren, um den gewünschten, zu testenden Zustand zu erreichen
- Den zu testenden Zustand der Klasse direkt setzen, wenn entsprechende Setter zur Verfügung stehen.
Testbarkeit ist ein Element von Codequalität
