Wenn du die privaten und geschützten Methoden testest, weißt du aber, was nicht funktioniert. Denn oft funktioniert zwar die public Methode, aber eine aufgerufene private macht Mist. Dann wird dir im Test angezeigt, dass die public-Methode nicht funktioniert, was genau genommen nicht stimmt. Wir machen Unit-Tests, nicht Schnittstellen-Tests.Thomas R. hat geschrieben:Getter und Setter Methoden sind i.A. Public - und damit zu testen!
Die Schnittstelle nach außen sind die Public Methoden. Wenn Sie (vollständig und korrekt) getestet sind ist die nach außen bereitgestellte Funktionalität gesichert (und damit indirekt auch die benutzten internen Methoden).
Selbstverständlich kann es während der Entwicklung bei besonderen privaten Methoden in seltenen Fällen sinnvoll sein diese zu testen - insbesondere wenn die nutzende Public Methode noch nicht komplett spezifiziert sein sollte .
MfG
Thomas R.
Aber in diesem Fall werden doch sowohl private als auch public-methode als falsch deklariert, was - wieder genau genommen - auch nicht stimmt, da public ein Folgefehler von private ist ( es sei du sparst den public test, wenn eine der aufgerufenen ( oder von denen gerufenen ( oder von denen gerufenen ( .... ))))) Methodenen nicht funktioniert.ralf.wenzel hat geschrieben:Wenn du die privaten und geschützten Methoden testest, weißt du aber, was nicht funktioniert. Denn oft funktioniert zwar die public Methode, aber eine aufgerufene private macht Mist. Dann wird dir im Test angezeigt, dass die public-Methode nicht funktioniert, was genau genommen nicht stimmt. Wir machen Unit-Tests, nicht Schnittstellen-Tests.
Weil die Tests der Testklasse nicht durchlaufen werden, wenn jemand die Domänenfestwerte ändert. Das müsste schon wer händisch machen. Man könnte höchstens einen Exit verwenden, um die entsprechende Klasse in denselben TA aufzunehmen, in dem die Domänenfestwert-Änderung steht. Bei gescheit eingestelltem Transport Organizer, der die Unit-Tests durchführt, müssten die auf einen Fehler laufen. Dazu müsste man den TA ermitteln, in dem die Änderung steht.... *grübel*black_adept hat geschrieben:Aber wenn du das so machst - warum prüfst du dann hier nicht auch gleich die Gleichheit von Domänenfestwerten gegen Klassenattribute in einem speziellen Test?
Jo, eine blöde Angewohnheit von mir. Du hast vollkommen recht.black_adept hat geschrieben:Ehrlich gesagt denkst du mir da zu kompliziert.
Meiner Erfahrung nach werden ABAP-Entwickler nur als Elitisten bezeichnet. Aus zwei Gründen:ralf.wenzel hat geschrieben:Warum, glaubt ihr, guckt die halbe IT-Welt auf ABAP-Entwickler herab? Ja, das ist wirklich so, sprecht mal mit Java- oder C#-Entwicklern, was die für ein Bild von uns haben. "Die können Befehle hintereinanderschreiben, aber von Software-Entwicklung verstehen die nix!"