Best Practice Testen von protected Methoden

[JunkerMartin]

In einer Webanwendung haben wir @RestController die von einer (abstrakte) Klasse erben; unter anderem auch "protected" Methoden. Ich möchte beim JUnit-Test auch wesentliche Zwischenergebnisse prüfen können - die können aber vom Test nicht abgefragt werden, weil die Methoden eben "protected" sind. Ich möchte sie aber aus Sicherheitsgründen auch nicht public machen. Meine Frage wäre, wie komme ich am einfachsten an die Daten. Hilft mir Spring hier weiter (ich arbeite mich da gerade ein; habe aber für einen solchen Ansatz noch nichts gefunden)?

 

[stg]

Mit Unit-Test testet man eigentlich die public API, was die Frage absolet macht.

Grundsätzlich kannst du aber protected Methoden natürlich testen, indem du die Testklasse ins gleiche package schiebst, wie die zu testende Klasse. (Dafür muss die Testklasse auch nicht im selben Folder liegen wie der source code)

 

[JunkerMartin]

Wenn man einfach von JUnit her denkt, hast Du sicher recht. Das heißt doch aber noch lange nicht, dass es keine Möglichkeiten gäbe. Wenn mir nichts weiter einfällt werde ich die Methoden in eine andere Klasse auslagern die auc über eine abstrakte Klasse beschrieben wird Über DI würde ich diese Klasse dann für den Test mit einer anderen Klasse erweitern die eine public getter darauf definieren.
Das ist nicht schön, weil man quasi Code für den Test macht, aber damit habe ich in Produktion die Methoden weiter versteckt und zum Testen bekomme ich die Ergebnisse.
Aber vielleicht gibt es ja einen eleganteren Weg; beim Durcharbeiten von Spring habe ich schon einige überraschende Mittel kennengelernt; vielleicht geht ja noch mehr.

 

[stg]

Dass es keine Möglichkeit gibt, hab ich ja nie behauptet; ich habe doch sogar einen Lösungsansatz gepostet. Spricht da denn was gegen?

 

[JunkerMartin]

"stg is cool" - das mag ja sein; vermutlich cooler als ich; ich habe keinen blassen Dunst wie mir das bei meiner Fragestellung helfen soll.

 

[thecain]

Grundsätzlich kannst du aber protected Methoden natürlich testen, indem du die Testklasse ins gleiche package schiebst, wie die zu testende Klasse. (Dafür muss die Testklasse auch nicht im selben Folder liegen wie der source code)

So gehts doch...

In Produktivem Code sollte sich nie Code befinden, der nur für Tests da ist, sonst ist das nicht für viel.

Dann würde ich mir lieber via reflection die Methode aus der Testklasse aufrufen, aber wieviel Sinn der Test dann noch macht ist fraglich.

Grundsätzlich sollte sich die protected Methode ja durch den Aufruf ein public Methode testen lassen. Sie wird ja wohl oder übel von irgend jemandem aufgerufen.

 

[stg]

"stg is cool" - das mag ja sein; vermutlich cooler als ich; ich habe keinen blassen Dunst wie mir das bei meiner Fragestellung helfen soll.

Das ist meine Signatur ...


Die Aussage mit dem Lösungsvorschlag war auf diesen Abschnitt bezogen:

Grundsätzlich kannst du aber protected Methoden natürlich testen, indem du die Testklasse ins gleiche package schiebst, wie die zu testende Klasse. (Dafür muss die Testklasse auch nicht im selben Folder liegen wie der source code)

 

[JunkerMartin]

Ja natürlich; aus demselben Package kann man auf die protected Methoden zugreifen - klar. Mir schwebte eine Form der Unabhängikeit der Testmethode von dem Code vor. Bei meiner Beschäftigung mit Spring hat mich die Injection von privaten Attributen (ohne Setter) stark beeindruckt; es hätte mich sehr interessiert ob es in Richtung Methoden auch so was gibt. Nun habe ich mich ein paar Tage mit AOP und AspectJ beschäftigt; das ist auch toll aber hilft mir in meiner Frage nicht unbedingt weiter.
Es muss also so gehen wie Du vorgeschlagen hast.
Danke auf jeden Fall.