AssertJ - Einführung - Versionsgeschichte

Ullrich: Ullrich verschob die Seite AssertJ Einführung nach AssertJ - Einführung, ohne dabei eine Weiterleitung anzulegen

2021-07-17T13:07:56Z

Ullrich verschob die Seite AssertJ Einführung nach AssertJ - Einführung, ohne dabei eine Weiterleitung anzulegen

← Nächstältere Version	Version vom 17. Juli 2021, 13:07 Uhr
(kein Unterschied)

Ullrich am 17. Juli 2021 um 13:05 Uhr

2021-07-17T13:05:07Z

Änderungen zeigen

Ullrich: Ullrich verschob die Seite Einführung in AssertJ nach AssertJ Einführung, ohne dabei eine Weiterleitung anzulegen

2021-04-21T20:35:27Z

Ullrich verschob die Seite Einführung in AssertJ nach AssertJ Einführung, ohne dabei eine Weiterleitung anzulegen

← Nächstältere Version	Version vom 21. April 2021, 20:35 Uhr
(kein Unterschied)

Ullrich: /* Geht das auch ohne λ? */

2021-04-13T14:54:20Z

Geht das auch ohne λ?

← Nächstältere Version		Version vom 13. April 2021, 14:54 Uhr
Zeile 206:		Zeile 206:
	});		});
	}}		}}
			= Mehrere Assertions in einem Test =
			Eine Grundregel für unit-Tests lautet: ''Eine'' Assertion je Test. Warum sollte man also mehrere Assertions in einem
			Test ausführen? Möchte man nach Ausführung eins Tests z.B. prüfen ob ein Adreß-Objekt korrekt befüllt ist, ist es in der Regel
			einfacher Alle Felder in einem Test abzufragen. Bisweilen hat man auch komplexere Situationen zu prüfen, etwa wenn ein
			Objekt-Geflecht erzeugt wird und die Struktur geprüft wird. Dann möchte man nicht einfach die Meldung bekommen "geht nicht"
			sondern genauere Information darüber was nicht stimmt.

			Das Problem bei der Test-Azsführung besteht nun darin, daß das Test-Framework -- in der Regeln JUnit -- nach dem Auftreten
			des ersten Fehlers den Test abbricht. Man führt den Test dann wieder und wieder aus und fixt jedesmal ''einen'' Fehler.

			AssertJ bietet -- mit den Soft-Assertions -- die Möglichkeit, die Assertion-Ergebnisse zu sammeln und am Ende der Test-Ausführung gesammelt und komplett
			auszuwerten. Es giebt zwei Möglichkeiten die Soft-Assertions anzuwenden zunächst die konventionelle Variante:
			{{java\|code=
			SoftAssertions bunch = new SoftAssertions();
			bunch.assertThat(adresse.getStrasse()).isEqulaTo("Alexanderplatz");
			bunch.assertThat(adresse.getHausnummer()).isEqulaTo(15);
			bunch.assertThat(adresse.getPostfach()).isNull();
			bunch.assertAll();
			}}
			Die Assertions werden in einem {{java\|SoftAssertions}-Objekt gesammelt und im Anschluß an die Ausführung
			durch den Aufruf von {{java\|assertAll()}} gesammelt ausgewertet. Der Knackpunkt bei dieser Variante ist,
			daß der Aufruf leicht vergessen werden kann. Dann wird im Unit -- unbemerkt -- nichts geprüft!

			Dieses Problem kann man mit der {{lambda}}-Variante umgehen:
			{{java\|code=
			SoftAssertions.assertSoftly(bunch -> {
			bunch.assertThat(adresse.getStrasse()).isEqulaTo("Alexanderplatz");
			bunch.assertThat(adresse.getHausnummer()).isEqulaTo(15);
			bunch.assertThat(adresse.getPostfach()).isNull();
			));
			}}
			Anstelle der unmittelbaren Ausführung wird der Block nun in einen {{lambda}}-Ausdruck verpackt.
			Das {{java\|SoftAssertions}-Objekt wird von der statischen Methode {{java\|assertSoftly}} erzeugt,
			der {{lambda}}-Ausdruck wird ausgeführt und {{java\|assertAll()}} wird am Ende ausgeführt.
			Kein Schritt kan vergessen werden.

			Der Block des {{lambda}}-Ausdrucks kann zudem alle beliebigen Java-Anweisungen enthalten,
			wie zusätzliche Berechnungen, lokale Variablen etcetera.

Ullrich am 10. April 2021 um 15:18 Uhr

2021-04-10T15:18:12Z

← Nächstältere Version		Version vom 10. April 2021, 15:18 Uhr
Zeile 1:		Zeile 1:
			[[Category:Java]]
	= Die grundlegende Syntax =		= Die grundlegende Syntax =
	Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein.		Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein.

Ullrich: /* Die grundlegende Syntax */

2021-04-08T11:04:36Z

Die grundlegende Syntax

← Nächstältere Version		Version vom 8. April 2021, 11:04 Uhr
Zeile 10:		Zeile 10:
	typischerweise beschreibt er eine lokale Variable, ein Objekt, oder ein Methoden-Aufruf.		typischerweise beschreibt er eine lokale Variable, ein Objekt, oder ein Methoden-Aufruf.
	Auf dem damit erzeugten Objekt kann man -- je nach Typ -- eine Reihe von Methoden aufrufen, die die zu prüfende Eigenschaft darstellen.		Auf dem damit erzeugten Objekt kann man -- je nach Typ -- eine Reihe von Methoden aufrufen, die die zu prüfende Eigenschaft darstellen.
	Betrachten wir mal als Beispiel die Prüfung, ob {{java\|2 + 2}} tatsächlich {{java\|4} ergibt. Dafür schreiben wir zunächst einmal		Betrachten wir mal als Beispiel die Prüfung, ob {{java\|2 + 2}} tatsächlich {{java\|4}} ergibt. Dafür schreiben wir zunächst einmal
	{{java\|code=		{{java\|code=
	Assertions.asserThat(2 + 2)		Assertions.asserThat(2 + 2)

Ullrich: /* Die grundlegende Syntax */

2021-04-04T11:05:43Z

Die grundlegende Syntax

← Nächstältere Version		Version vom 4. April 2021, 11:05 Uhr
Zeile 22:		Zeile 22:
	stehen unterschiedliche Methoden zur Überprüfung zur Verfügung.		stehen unterschiedliche Methoden zur Überprüfung zur Verfügung.
	In den folgenden Abschnitten werden die meistverwendeten vorgestellt.		In den folgenden Abschnitten werden die meistverwendeten vorgestellt.


	= Ausführung =		= Ausführung =
	Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:		Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:

Ullrich: /* Ausführung */

2021-04-04T11:04:38Z

Ausführung

← Nächstältere Version		Version vom 4. April 2021, 11:04 Uhr
Zeile 24:		Zeile 24:


	== Ausführung ==		= Ausführung =
	Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:		Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:
	Assertions.assertThat(2+2).isEqualTo(5);		Assertions.assertThat(2+2).isEqualTo(5);
Zeile 33:		Zeile 33:
	org.junit.ComparisonFailure: [2 + 2] expected:<[5]> but was:<[4]>		org.junit.ComparisonFailure: [2 + 2] expected:<[5]> but was:<[4]>

	=Objekte=		= Objekte =

	==Gleichheit==		==Gleichheit==
	Normalerweise vergleicht man Objekte auf inhaltliche Gelichheit über die {{java\|.equals()}} Methode. Das geht in AssertJ mit:		Normalerweise vergleicht man Objekte auf inhaltliche Gelichheit über die {{java\|.equals()}} Methode. Das geht in AssertJ mit:

Ullrich: /* Die grundlegende Syntax */

2021-04-04T11:03:59Z

Die grundlegende Syntax

← Nächstältere Version		Version vom 4. April 2021, 11:03 Uhr
Zeile 2:		Zeile 2:
	Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein.		Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein.
	Jede Assertion in AssertJ folgt dem gleichen Aufbau; umgangsprachlich läßt sie so ausdrücken:		Jede Assertion in AssertJ folgt dem gleichen Aufbau; umgangsprachlich läßt sie so ausdrücken:
	{{quote\|assert that X has property Y}}		{{quote\|assert that object X has property Y}}
	oder auf Deutsch:		oder auf Deutsch:
	{{quote\|stelle sicher, daß X die Eigenschaft Y besitzt}}		{{quote\|stelle sicher, daß das Objekt X die Eigenschaft Y besitzt}}
	Sie besteht also aus zwei Teilen: dem zu prüfenden Objekt X und der Prüfung Y. Jede -- also zumindest fast jede -- Assertion beginnt mit dem Aufruf der statischen Methode:		Sie besteht also aus zwei Teilen: dem zu prüfenden Objekt X und der Prüfung Y. Jede -- also zumindest fast jede -- Assertion beginnt mit dem Aufruf der statischen Methode:
	{{java\|code=Assertions.assertThat(...)}}		{{java\|code=Assertions.assertThat(...)}}
Zeile 24:		Zeile 24:


	= Ausführung =		== Ausführung ==
	Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:		Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:
	Assertions.assertThat(2+2).isEqualTo(5);		Assertions.assertThat(2+2).isEqualTo(5);

Ullrich: Die Seite wurde neu angelegt: „= Die grundlegende Syntax = Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein. Jede Assertion in AssertJ folgt dem gleichen Aufbau; umgangspra…“

2021-04-04T11:01:49Z

Die Seite wurde neu angelegt: „= Die grundlegende Syntax = Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein. Jede Assertion in AssertJ folgt dem gleichen Aufbau; umgangspra…“

Neue Seite

= Die grundlegende Syntax =
Die Struktur von AssertJ-Anweisungen könnte einfacher nicht sein.
Jede Assertion in AssertJ folgt dem gleichen Aufbau; umgangsprachlich läßt sie so ausdrücken:
{{quote|assert that X has property Y}}
oder auf Deutsch:
{{quote|stelle sicher, daß X die Eigenschaft Y besitzt}}
Sie besteht also aus zwei Teilen: dem zu prüfenden Objekt X und der Prüfung Y. Jede -- also zumindest fast jede -- Assertion beginnt mit dem Aufruf der statischen Methode:
{{java|code=Assertions.assertThat(...)}}
Sie hat als einzigen Parameter einen Java-Ausdruck der das zu prüfende Objekt liefert. Der Ausdruck kann so ziemlich alles sein,
typischerweise beschreibt er eine lokale Variable, ein Objekt, oder ein Methoden-Aufruf.
Auf dem damit erzeugten Objekt kann man -- je nach Typ -- eine Reihe von Methoden aufrufen, die die zu prüfende Eigenschaft darstellen.
Betrachten wir mal als Beispiel die Prüfung, ob {{java|2 + 2}} tatsächlich {{java|4} ergibt. Dafür schreiben wir zunächst einmal
{{java|code=
Assertions.asserThat(2 + 2)
}}
Tippen wir nun einen Punkt ein, bietet Eclipse eine Fülle von Methoden an -- wir möchten auf Gleichheit
testen, wählen für unser Beispiel {{java|.isEqualTo()}} aus und schreiben
{{java|code=
Assertions.asserThat(2 + 2).isEqualTo(4);
}}
Schon ist die Assertion fertig. Abhängig vom Typ des zu prüfenden Ausdrucks im {{java|assertThat}}-Aufruf
stehen unterschiedliche Methoden zur Überprüfung zur Verfügung.
In den folgenden Abschnitten werden die meistverwendeten vorgestellt.

= Ausführung =
Geht die Assertion schief, bemüht sich AssertJ um eine möglichst hilfreiche Meldung:
Assertions.assertThat(2+2).isEqualTo(5);
org.junit.ComparisonFailure: expected:<[5]> but was:<[4]>
Sollte die Meldung nicht ausreichen, kann man nach dem Aufruf von {{java|assertThat}} eine Erklärung einfügen indem man
die {{java|.as()}}-Methode aufruft:
Assertions.assertThat(2 + 2).as("2 + 2").isEqualTo(5);
org.junit.ComparisonFailure: [2 + 2] expected:<[5]> but was:<[4]>

=Objekte=
==Gleichheit==
Normalerweise vergleicht man Objekte auf inhaltliche Gelichheit über die {{java|.equals()}} Methode. Das geht in AssertJ mit:
{{java|code=assertThat(x).isEqualsTo(Y)}}
Vergleicht man enum-Ausprägungen oder möchte sicherstellen -- was einem Vergleich mit == entspricht -- verwendet man
{{java|code=assertThat(x).isSameAs(Y)}}

==Null oder nicht Null==
Dafür gibt es zwei Methoden mit naheliegendem Namen:
{{java|code=
assertThat(x).isNull()
assertThat(x).isNotNull()
}}
==Welcher Typ?==
Mit
{{java|code=assertThat(X).isInstanceOf(Foo.class);}}
kann geprüft werden, ob das Objekt eine Instanz der angegebenen Klasse ist.
==Boolean und boolean==
Für die Boolean-Typen stehen zwei Methoden mit offensichtlichem Verhalten zur Verfügung:
{{java|code=
Assertions.assertThat(x).isTrue()
Assertions.assertThat(x).isFalse()
}}
Die Methoden funktionieren für beide Boolean-Typen, für {{java|Boolean}} ohne die Gefahr einer Null-Pointer-Exception.

==Optional==
Bevor man den Inhalt eines Optional-Objekts prüfen kann, muß man ihn erst auspacken;
ein Job den AssertJ für uns übernimmt und dabei auch darauf achtet, ob statt eines validen Objekts
vielleicht {{java|null}} übergeben wurde:
{{java|code=Assertions.assertThat(x).contains("foo")}}
Ist der Inhalt egal, kann man auch direkt die Präsenz oder Abwesenheit eines Wertes abfragen:
{{java|code=
Assertions.assertThat(x).isPresent()
Assertions.assertThat(x).isNotPresent()
}}
Statt {{java|.isNotPresent()}} kann auch {{java|.empty()}} verwendet werden.
Interessiert nur der Typ des enthaltenen Objekts, hilft AssertJ uns auch:
{{java|code=Assertions.assertThat(x).containsInstanceOf(String.class)}}
Man beachte den Unterschied zu {{java|.instanceOf()}}, das den Typ von {{java|x}} prüft,
während {{java|containsInstanceOf()}} den Typ von {{java|x.get()}} prüft.

== Listen, Arrays, Kollektionen ==
Besonders hilfreich ist AssertJb ei der Prüfung von Listen aller Art.
Sehr angenehm ist dabei die gleichartige Behandlung von Typen wie Streams, Arrays und Collections wie List und Set
die alle mit den gleichen Methoden getestet werden. Das bedeutet, daß weniger Methoden zu lernen sind und
wenn sich der Typ eines Ausdrucks ändert - z.B. von {{java|List}} nach {{java|Stream}} - muß der Test nicht angepaßt werden.

Das Einfachste ist die Suche nach bestimmten Werten:
{{java|code=Assertions.assertThat(liste).contains("x", "y");}}
Die Prüfung gelingt, wenn die Liste -- gegebenenfalls neben anderen Strings -- die String "x" und "y"
an beliebiger Stelle enthält. Daneben gibt es eine ganze Legion von contains-Methoden wie z.B.
{{java|code=
containsAnyOf
containsExactly
containsExactlyInAnyOrder
containsNull
containsOnly
}}
Analog dazu gibt es negierte Methoden, die mit {{java|doesNotContain}} beginnen.

Bei simplen Typen wie {{java|String} oder Zahlen funktionieren die contains-Methoden sehr gut. Bei Objekten muß man in die Objekte
hineinschauen und wenn die {{java|.equals}}-Methode nicht passend implementiert wurde, erhält man unbefriedigende Ergebnisse.

Verwendet man λ-Prädikate kann man {{java|anyMatch}} und {{java|noneMatch}} verwenden.
Möchten wir etwa sicherstellen, daß die Liste ein Objekt mit der ID "5" enthält, könnte das so aussehen:
{{java|code=
Assertions.assertThat(liste).anyMatch(x -> x.id().equals(5));
}}
= Selbstgebaute Test-Bedingungen -- Conditions =
Grundsätzlich lassen sich alle Test-Ausdrücke mit den genannten Konstrukten formulieren. Strenggenommen kann man ja jeden Test als
boolean-Ausdruck formulieren und dann auf True oder False prüfen. Das führt jedoch zu unübersichtlichen Tests und zu endlosen
Code-Duplikationen. Wiederkehrende Prüfungen lassen sich mit Hilfe von wiederverwertbaren {{java|Conditions}} definieren.
Betrachten wir dazu als einfaches Beispiel (der Einfachheit halber ohne getter und setter) eine Person die einen Namen
hat und einer Abteilung zugeordnet ist:
{{java|code=
class Person {
String name;
String abteilung;

Person(String name, String abteilung) {
this.name = name;
this.abteilung = abteilung;
}

@Override
public String toString() {
return name;
}
}
}}
Um zu testen ob eine Person zur Abteilung "X" gehört kann ein Prädikat mit Hilfe der Methode {{java|matches()}} nutzen:
{{java|code=
Assertions.assertThat(person).matches(p -> p.abteilung.equals("X"));
Assertions.assertThat(person).matches(p -> p.abteilung.equals("X"), "ist in X");
}}
Funktional sind beide Varianten identisch, die Angabe der Beschreibung im zweiten Falle erleichtert aber die Interpretation
der Fehlermeldung. Um nicht jedesmal das Prädikat und die Beschreibung neu tippen zu müssen, kann man beides zu einer
{{java|Condition}} zusammenfassen und ''irgendwo'' ablegen:
{{java|code=
Condition<Person> InAbteilungX = new Condition<>(p -> p.abteilung.equals("X"), "ist in X");
}}
Der Aufruf sieht dann im Unit-Test so aus:
{{java|code=
Assertions.assertThat(person).is(InAbteilungX);
}}
Conditions lassen sich mit {{java|not()}} negieren, mit {{java|allOf()}} -- das entspricht einer und-Verknüpfung -- und mit
{{java|anyOf()}} -- das entspricht einer oder-Verknüpfung -- verbinden.

Für die Erzeugung von Conditions kann man auch Factory-Methoden definieren. Hier wird zu einer Abteilung eine Condition erzeugt,
die die Zugehörigkeit einer Person zu einer Abteilung testet:
{{java|code=
static Condition<Person> inAbteilung(String abt) {
Predicate<Person> pred = p -> p.abteilung.equals(abt);
String description = "Abteilung " + abt;
return new Condition<Person>(pred, description);
}
}}
im Unit-Test sieht der Aufruf damit so aus:
{{java|code=Assertions.assertThat(person).is(inAbteilung("X"));}}
Ist die Condition nicht erfüllt, erhält man folgende Ausgabe. Für die Ausgabe des Namens ist die {{java|toString}}-Methode
der Klasse {{java|Person}} verantwortlich:
java.lang.AssertionError:
Expecting:
<Kasimir>
to have:
<Abteilung X>

=Exceptions=
Mit der {{java|assertThat}}-Methode kann nicht getestet werden, ob bei einem Methoden-Aufruf eine Exception geworfen wird oder nicht.
Das funktioniert deshalb nicht, weil der Ausdruck, der {{java|assetThat}} als Argument übergeben wird ausgewertet wird ''bevor''
die {{java|assertThat}}-Methode ausgeführt wird.

Für den Test auf Exceptions wird die Ausführung in einen λ-Ausdrck verpackt, dieser einer geeigneten Methode übergeben und
as Ergebnis bei dessen Ausführung analysiert -- wie funktioniert das konkret?

Bei der ersten Variante wird ein λ-Ausdruck übergeben und ''anschließend'' die erwartete Exception angegeben.
Im Beispiel wird die Methode {{java|foo}} des Objekts {{java|subject}} aufgerufen:
{{java|code=Assertions.assertThatThrownBy(() -> subject.foo()).isInstanceOf(NullPointerException.class);}}
Die erwartete Exception-Klasse wird von der Methode {{java|isInstanceOf()}} geprüft.

Die zweite Variante legt ''erst'' die erwartete Exeption fest und prüft ''dann'' den λ-Ausdruck:
{{java|code=Assertions.assertThatExceptionOfType(NullPointerException.class).isThrownBy(() -> subjekt.foo());}}
Die zweite Variante verstößt gegen das sonst in AssertJ durchgängige Konzept ''erst'' den Test-Aufruf und
''dann'' das erwartete Ergebnis anzugeben. Es gibt jedoch einige Methode für oft benötigte Exceptions:
{{java|code=
Assertions.assertThatIllegalStateException().isThrownBy(() -> subjekt.foo());
Assertions.assertThatIllegalArgumentException().isThrownBy(() -> subjekt.foo());
Assertions.assertThatNullPointerException().isThrownBy(() -> subjekt.foo());
Assertions.assertThatIOException().isThrownBy(() -> subjekt.foo());
}}

==Geht das auch ohne λ?==
Grundsätzlich sind λ-Ausdrücke und anonyme Klassen austauschbare Konzepte.
Man kann daher λ-Ausdrücke durch Klassen ersetzen die das geeignete (funktionale) Interface implementieren.
Die Methode {{java|assertThatThrownBy()}} akzeptiert als Parameter ein Objekt das das Interface
{{java|ThrowingCallable}} implementiert. Daher kann man die erste Variante mit einer anonymen Klasse so schreiben:
{{java|code=
Assertions.assertThatThrownBy(new ThrowingCallable() {
@Override
public void call() throws Throwable {
subjekt.foo();
}
}).isInstanceOf(NullPointerException.class);
}}
Die zweite Variante sieht dann -- wir verwenden hier die Spezial-Methode für Nullpointer-Exceptions -- so aus:
{{java|code=
Assertions.assertThatNullPointerException().isThrownBy(new ThrowingCallable() {
@Override
public void call() throws Throwable {
subjekt.foo();
}
});
}}