Ullrich: Die Seite wurde neu angelegt: „Category:Java Category:junit Um einen parametrisierte Test-Methode mit Daten zu versorgen bieten sich Methoden als Testdaten-Provider an. Eine solcher Provider-Methode liefert einen {{java|Stream}} von Testdaten-Sätzen. Ein Testdaten-Satz besteht in der Regel auf mehreren Einzeldaten, er kann aber natürlich auch aus einem einzelnen Datum bestehen. Jeder Satz ist in ein {{java|Arguments}}-Objekt verpackt und besteht daher immer aus Objekten; Date…“

2024-03-19T19:15:17Z

Die Seite wurde neu angelegt: „Category:Java Category:junit Um einen parametrisierte Test-Methode mit Daten zu versorgen bieten sich Methoden als Testdaten-Provider an. Eine solcher Provider-Methode liefert einen {{java|Stream}} von Testdaten-Sätzen. Ein Testdaten-Satz besteht in der Regel auf mehreren Einzeldaten, er kann aber natürlich auch aus einem einzelnen Datum bestehen. Jeder Satz ist in ein {{java|Arguments}}-Objekt verpackt und besteht daher immer aus Objekten; Date…“

Neue Seite

[[Category:Java]]
[[Category:junit]]
Um einen parametrisierte Test-Methode mit Daten zu versorgen bieten sich Methoden als Testdaten-Provider an.
Eine solcher Provider-Methode liefert einen {{java|Stream}} von Testdaten-Sätzen. Ein Testdaten-Satz besteht in der Regel
auf mehreren Einzeldaten, er kann aber natürlich auch aus einem einzelnen Datum bestehen. Jeder Satz ist in
ein {{java|Arguments}}-Objekt verpackt und besteht daher immer aus Objekten; Daten atomarer Typen werden dabei in
Objekte der korrespondierenden Klassen verpackt.

Betrachten wir eine einfache Test-Methode die für die Ausführung zwei Strings benötigt.
Wie jede Test-Methode die eine nichtleere Parameterliste hat, muß sie mit der Annotation {{java|@ParameterizedTest}}
versehen sein:
{{java|code=
@ParameterizedTest
void passwortWirdNichtAkzeptiert(String passwort, String grund) {
assertThat(policy.validate(passwort)).as(grund).isFalse();
}
}}
== Variante 1: die statische Methode ==
Der einfachste Weg einen Testdaten-Provider zu definieren führt über eine statische Methode
die sich in der selben Klasse befindet wie die Test-Methode:
{{java|code=
static Stream<Arguments> pwdWirdNichtAkzeptiert() {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}}
Stimmt der Name des Testdaten-Providers mit dem Namen der Test-Methode überein, kann man den Parameter
in der Annotation auch weglassen. Für diese Variante gelten folgende Einschränkungen:
* Die Methode muß in der gleichen Klasse liegen wie die Test-Methode
* Die Methode muß als {{java|static}} deklariert sein
* Die Methode darf ''nicht'' {{java|private}} deklariert sein

== Variante 2: die qualifizierte statische Methode ==
Nachteil der ersten Variante ist, daß sich der Testdaten-Provider in der gleichen Klasse befinden muß
wie die Test-Methode. Das gilt auch, wenn sich die Methode in einer Member Class oder einer Inner Class befindet.
Damit lassen sich keine Testdaten-Provider definieren, die von mehreren geschachtelte Test-Klassen
-- per Annotation {{java|@Nested}} -- gemeinsam genutzt werden.

Befindet sich der Testdaten-Provider in einer anderen Klasse als die Test-Methode, kann man zusätzlich zur Methode
die Klasse angeben in der sich die Methode befindet. Die Package-Angabe muß '''voll qualifiziert''' sein, die Methode
wird mit {{java|#}} getrennt angefügt:
{{java|code=
MethodSource("org.mletkin.unittest.TestDaten#pwdWirdNichtAkzeptiert")
}}
Wie in Variante 1 erfolgt die Angabe in Form eines Strings. Das ist fehleranfällg, weil die Klasse und die Methode
erst zur Laufzeit -- also bei der Test-Ausführung -- auf Existenz geprüft werden.

Man kann das mitigieren, indem man den String in eine Konstante auslagert:
{{java|code=
private static final String TEST_DATA = "org.mletkin.unittest.TestDaten#pwdWirdNichtAkzeptiert";
...
@MethodSource(TEST_DATA)
}}
Das eröffnet zum einen die Möglichkeit Test-Methoden zentral bereitzustellen und zum anderen die Möglichkeit
die Strings auf Gültigkeit zu überprüfen. Das geschieht dann zwar auch erst zur Laufzeit, der Fehler tritt
dann aber wenigstens da auf wo er geschehen ist.

== Variante 3: die Testdaten-Provider-Klasse ==
Eine weitere Möglichkeit den Testdaten-Provider zu implementieren ist die Definition in einer eigenen Klasse.
Eine solche Klasse kann allerdings nur eine einzige Testdaten-Methode anbieten, da der Zugriff über ein Interface erfolgt:
{{java|code=
public class UngueltigePassworte implements ArgumentsProvider {
@Override
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}
}}
Die Testdaten-Provider-Klasse muß das Interface {{java|ArgumentsProvider}} implementieren und dazu die oben gezeigte Methode
implementierten. Sie erhält als Argument ein Kontext-Objekt das Informationen zur Umgebung der Test-Ausführung enthält.
In unserem Beispiel machen wir keinen Gebrauch davon.

Die Verwendung erfolgt über die Annotation {{java|@ArgumentsSource}}, der jetzt die Testdaten-Provider-Klasse in Form eines
{{java|Class}}-Objekts übergeben wird:
{{java|code=
@ArgumentSource(UngueltigePassworte .class)
}}
Im Gegensatz zur {{java|@MethodSource}}-Verwendung in den vorangegangenen Varianten wird hier schon zur Compile-Zeit sichergestellt
daß die Testdaten-Provider-Klasse und die -Methode existieren.

Testdaten-Provider - Versionsgeschichte