Gestaltung von Unit-Tests - Versionsgeschichte

Ullrich: /* Gemeinsame Test-Objekte */

2021-09-09T05:42:59Z

Gemeinsame Test-Objekte

← Nächstältere Version		Version vom 9. September 2021, 05:42 Uhr
Zeile 93:		Zeile 93:
	@Test		@Test
	public void fahrenheit32ErgibtCelsius0() {		public void fahrenheit32ErgibtCelsius0() {
	~~Assertions~~.~~assertThat~~(rechner.farenheit2Celsius(32)~~).isEqualTo(0~~);		Assert.assertEquals(0, rechner.farenheit2Celsius(32));
	}		}
	}		}
	}}		}}

Ullrich: /* Ergebnis prüfen */

2021-09-09T05:42:27Z

Ergebnis prüfen

← Nächstältere Version		Version vom 9. September 2021, 05:42 Uhr
Zeile 55:		Zeile 55:

	=== Ergebnis prüfen ===		=== Ergebnis prüfen ===
	Am Ende des Unit-Tests muß immer eine Prüfung stehen~~; ohne~~ Assertion ist der Test kein Test!		Am Ende des Unit-Tests muß immer eine Prüfung stehen, eine "Assertion. Ohne eine Assertion ist der Test kein Test!
	Mit einer geeigneten Assertion prüft man, ob das gewünschte Ergebnis eingetreten ist.		Mit einer geeigneten Assertion prüft man, ob das gewünschte Ergebnis eingetreten tatsächlich ist.

	Assertion kann man mit der {{java\|Assert}}-Klasse aus JUnit4 formulieren		Assertion kann man mit der {{java\|Assert}}-Klasse aus JUnit4 formulieren
	oder mit der Zusatzbibliothek {{java\|AssertJ}}		oder mit der Zusatzbibliothek {{java\|AssertJ}}.

	== Variationen ==		== Variationen ==

Ullrich: /* Ergebnis prüfen */

2021-09-09T05:41:37Z

Ergebnis prüfen

← Nächstältere Version		Version vom 9. September 2021, 05:41 Uhr
Zeile 57:		Zeile 57:
	Am Ende des Unit-Tests muß immer eine Prüfung stehen; ohne Assertion ist der Test kein Test!		Am Ende des Unit-Tests muß immer eine Prüfung stehen; ohne Assertion ist der Test kein Test!
	Mit einer geeigneten Assertion prüft man, ob das gewünschte Ergebnis eingetreten ist.		Mit einer geeigneten Assertion prüft man, ob das gewünschte Ergebnis eingetreten ist.

			Assertion kann man mit der {{java\|Assert}}-Klasse aus JUnit4 formulieren
			oder mit der Zusatzbibliothek {{java\|AssertJ}}

	== Variationen ==		== Variationen ==

Ullrich: /* Test-Methoden komprimieren */

2021-09-09T05:40:06Z

Test-Methoden komprimieren

← Nächstältere Version		Version vom 9. September 2021, 05:40 Uhr
Zeile 68:		Zeile 68:
	@Test		@Test
	public void fahrenheit32ErgibtCelsius0() {		public void fahrenheit32ErgibtCelsius0() {
	~~Assertions~~.~~assertThat~~(new TemperaturRechner().fahrenheit2Celsius(32)~~).isEqualTo(0~~);		Assert.assertEquals(0, new TemperaturRechner().fahrenheit2Celsius(32));
	}		}
	}}		}}

Ullrich: /* Regeln für Test-Klassen und Test-Methoden */

2021-09-09T05:39:34Z

Regeln für Test-Klassen und Test-Methoden

← Nächstältere Version		Version vom 9. September 2021, 05:39 Uhr
Zeile 37:		Zeile 37:
	TemperaturRechner rechner = new TemperaturRechner();		TemperaturRechner rechner = new TemperaturRechner();
	long celsius = rechner.fahrenheit2Celsius(32);		long celsius = rechner.fahrenheit2Celsius(32);
	~~Assertions~~.~~assertThat~~(celsius~~).isEqualTo(0~~);		Assert.assertEquals(0, celsius);
	}		}
	}}		}}

Ullrich: Die Seite wurde neu angelegt: „Category:Java Kategorie:Ausbildung Im Folgenden sind einige Konventionen für das Schreiben von Unit-Tests zusammengestellt. Es gibt viele verschiedene…“

2021-08-01T11:49:56Z

Die Seite wurde neu angelegt: „Category:Java Kategorie:Ausbildung Im Folgenden sind einige Konventionen für das Schreiben von Unit-Tests zusammengestellt. Es gibt viele verschiedene…“

Neue Seite

[[Category:Java]]
[[Kategorie:Ausbildung]]
Im Folgenden sind einige Konventionen für das Schreiben von Unit-Tests zusammengestellt.
Es gibt viele verschiedene Meinungen und Ansätze an Unit-Tests heranzugehen; die folgenden Regeln haben sich
in der Praxis als eine einfache Variante bewährt um schnell vorwärts zu kommen.

Wichtig ist, daß man sich für ein Vorgehen entscheidet und das dann
möglichst konsequent durchzieht, am Besten in Absprache mit dem Entwicklungs-Team mit dem man gerade
arbeitet.
Merke: Der Unit-Test soll den Entwickler unterstützen und jedem helfen der sie liest.

== Regeln für Test-Klassen und Test-Methoden ==
Für die Beispiele betrachten wir eine einfache Klasse mit einer Methode
{{java|code=
class TemperaturRechner {
public long fahrenheit2Celsius(long f) {
return (5 * f - 160) / 9;
}
}
}}

* Für die zu testende Klasse wird eine eigene Test-Klasse mit dem Zusatz Test erstellt,
:Zur Klasse {{java|TemperaturRechner}} erstellt man eine Klasse {{java|TemperaturRechnerTest}}
* Alle Test-Methoden haben die gleiche Form (Kein Prä- oder Suffix "Test" am Methodennamen)
:{{java|@Test public void xx(){...} }}
* Der Bezeichner der Test-Methoden soll in einem Satz beschreiben was getestet wird und was das erwartete Ergebnis ist.
* Getestet wird das Interface der zu testenden Klasse:
:Alle Methoden mit Ausnahme der private-Methoden werden getestet.
* Wenn zu viele Tests für eine Klasse zusammenkommen, kann man die Tests auch auf mehrere Testklassen verteilen. Schreibt man etwa für die Methode der obigen Klasse eine eigene Test-Klasse könnte si {{java|TemperaturRechnerFahrenheit2Cslsius}} heißen.

Nach diesen Regeln wird ein Unit-Test erstellt, der prüft, ob 32°F tatsächlich auf 0°C
umgerechnet werden. Da der Methodenname nicht mit einer Ziffer beginnen kann, steht dabei die
Einheit vor dem Wert. Alternativ kann man die Zahlen auch ausschreiben oder ein Wort voranstellen.
{{java|code=
@Test
public void fahrenheit32ErgibtCelsius0() {
TemperaturRechner rechner = new TemperaturRechner();
long celsius = rechner.fahrenheit2Celsius(32);
Assertions.assertThat(celsius).isEqualTo(0);
}
}}
Wie immer ist beim Finden passender Namen Kreativität gefragt.

== Aufbau eines Unit-Tests ==
Ein Unit-Test -- also einer einzelnen Testmethode -- hat in der Regel drei Schritte:

=== Test vorbereiten ===
In diesem Schritt werden Voraussetzungen für den Test geschaffen, zum Beispiel Test-Objekte oder -Daten erzeugt.
in der Literatur wird der Versuchsaufbau auch als Fixture oder Setup bezeichnet.
Hier werden ggf. auch Voraussetzungen dokumentiert.
Wenn zum Beispiel ein nicht-leeres Objekt benötigt wird, kann man das mit einer Assumption sicherstellen.

=== Test durchführen ===
In diesem Schritt wird die zu testende Methode in "geeigneter Weise" aufgerufen.

=== Ergebnis prüfen ===
Am Ende des Unit-Tests muß immer eine Prüfung stehen; ohne Assertion ist der Test kein Test!
Mit einer geeigneten Assertion prüft man, ob das gewünschte Ergebnis eingetreten ist.

== Variationen ==

=== Test-Methoden komprimieren ===
Die drei – im vorangegangenen Abschnitt aufgeführten – Schritte müssen nicht explizit von einander getrennt sein.
Kürzere Methoden sind oft leichter zu lesen als lange, erlaubt ist alles, was jeder andere Entwickler ohne
Verrenkung verstehen kann.
Den Beispiel-Test kann man auch so zusammendampfen:
{{java|code=
@Test
public void fahrenheit32ErgibtCelsius0() {
Assertions.assertThat(new TemperaturRechner().fahrenheit2Celsius(32)).isEqualTo(0);
}
}}

=== Gemeinsame Test-Objekte ===
Die meisten Test-Klassen konzentrieren sich auf eine einzelne zu testende Klasse und benötigen oft nur
eine einzige Instanz davon. Man kann sie daher als Feld der Test-Klasse deklarieren, initialisieren und
in jedem Test verwenden. Das spart jedesmal eine Deklaration.

Als Bezeichner kann man z.B. {{java|testInstanz}} oder {{java|testObjekt}} verwenden, aber auch einen
zur Klasse passenden Begriff wie im Code-Beispiel unten.

Erlaubt ist alles, was leserlich ist, je leichter umso besser. Abkürzungen sollten immer dann vermieden
werden, wenn sie für die Leserschaft nicht selbstverstädlich ist. "sut" anstelle von "subjectUnderTest"
führt eher zur Verwirrung.

Der Beispiel-Test sieht dann so aus:
{{java|code=
public void TemperaturRechnerTest {
TemperaturRechner rechner = new TemperaturRechner();
@Test
public void fahrenheit32ErgibtCelsius0() {
Assertions.assertThat(rechner.farenheit2Celsius(32)).isEqualTo(0);
}
}
}}