Testen von abstrakten Klassen

Java-Forum Allgemeine Themen
1

Hi,

ich habe aus mehreren Klassen, die das selbe Interface implementieren, gemeinsames Verhalten in eine abstrakte Elternklasse extrahiert.
Dort liegt “echtes” Verhalten, bspw. wie mit bestimmten Zuständen umgegangen werden soll.
Wie kann dieses Verhalten jetzt sinnvoll getestet werden, ohne eine Implementierung der abstrakten Methoden für die Tests vorzugeben?

Viele Grüße
Christian

2

Mit Mockito:AbstractClass ac = Mockito.mock(AbstractClass.classs,Mockito.CALL_REAL_METHODS);

Was dabei leider nicht funktioniert ist der Zugriff auf im Constructor initialisierte Variablen, denn der Constructor wird ja nicht ausgeführt…

besser wäre es übrigens gewesen, diese gemeinsame Funktionalität in eine normale Klasse zu packen und diese den Interface-Implementierungen als Constructor-Parameter mit zu geben…

bye
TT

3

Ja, ich würde auch Mockito nutzen. Das klappt wunderbar.

4

Ich nutze zwar JMockit, aber damit geht das sicher vergleichbar wie mit Mockito *. Ich hatte gehofft, dass es ein Paradigma gibt, welches eleganter oder etablierter ist, als die „brutale“ Variante.

Kannst du das genauer ausführen? Ich glaube nämlich nicht, dass das in meinem Fall wirklich Sinn machen würde.
Schematisch läuft das in der abstrakten Klasse etwa so ab:


@Override
public void something() {
    checkPreconditionsMaybeRaisingAnException();
    doSomething();
    someCommonPostprocessing();
}```

* Edit: nachlesbar ist das hier: [JMockit - Tutorial - Faking unspecified implementation classes](http://jmockit.org/tutorial/Faking.html#implementationClasses)

*** Edit ***

[quote=Timothy_Truckle;138279]Was dabei leider nicht funktioniert ist der Zugriff auf im Constructor initialisierte Variablen, denn der Constructor wird ja nicht ausgeführt...[/quote]
Das wäre ein kleines Manko - ein Konstruktorparameter wird in einer Methode, die durch das Interface deklariert wurde, einfach zurückgegeben.
5

fur Frage nach dem Einsatz Basisklasse an sich weiter in Thema

hier noch zum Testen oder fertig :wink:

6

[quote=cmrudolph]Jetzt, beim schreiben der Tests, stellt sich heraus, weshalb die Vererbung unpraktisch ist. Die Klasse lässt sich so gut wie nicht testen, weil die Sichtbarkeit der relevanten Methoden protected ist.[/quote]Wieso ist dass denn ein Problem?
Tests hat man doch immer im selben Package (aber unter src/test/java statt src/main/java)…

bye
TT

7

Danke für den Hinweis. Ich weiß nicht wie ich darauf kam, aber irgendwie hatte ich gedacht, dass protected die package-Sichtbarkeit ausschließt… :o

8

[ot]
(SEHR OT, aber) “Integrationstests” leg’ ich immer in ein anderes package. Sonst passiert es zu leicht, dass man in einem “Sample/Test” eine protected-Methode verwendet
[/ot]

9

Bei Integrationstests macht es ja auch Sinn, diese in ein komplett eigenes Modul zu packen.