Was gibt es Neues im JUnit 5.6.0 Release?

Vor kurzem wurde die Version 5.6.0 des JUnit Test-Frameworks veröffentlicht. Daher möchte ich hier gerne eine Übersicht über die Änderungen bzw. die neuen Funktionen geben.

@EnabledForJreRange und @DisabledForJreRange

Die erste Aktualisierung bezieht sich auf die Annotationen @EnabledForJreRange und @DisabledForJreRange. Mit diesen beiden Annotationen kann man nun einen Bereich von JRE-Versionen auswählen, für die das Ausführen von Tests ein- bzw. ausgeschaltet werden kann. Die Annotationen können auf Klassen- oder Methodenebene verwendet werden.

Dazu ein Codebeispiel:

@DisabledForJreRange(min = JRE.JAVA_8, max = JRE.JAVA_13)
public class TestDemo {
	@Test
	public void shouldCheckAsPerClassAnnotation() {
		assertTrue(true);
	}
}

Die Annotation @DisabledForJreRange wurde auf Klassenebene definiert. Hier sieht man die beiden Attribute min und max, mit denen man die minimale und maximal JRE-Version festlegen kann. In meinem Fall benutze ich Java 8 zur Ausführung der Tests. Dadurch wird der Test nicht ausgeführt:

Das nächste Beispiel beschreibt eine Anwendung der obigen Annotationen auf Methodenebene für verschiedene Fälle:

public class TestDemo {

	@Test
	@EnabledForJreRange(min = JRE.JAVA_8, max = JRE.JAVA_12)
	public void shouldCheckForJreRange() {
		assertTrue(true);
	}

	@Test
	@EnabledForJreRange(min = JRE.JAVA_9, max = JRE.JAVA_10)
	public void shouldCheckForJre() {
		assertTrue(true);
	}

	@Test
	@DisabledForJreRange(min = JRE.JAVA_8, max = JRE.JAVA_12)
	public void shouldNotCheckForJreRange() {
		assertTrue(true);
	}
}

Dieses Codebeispiel wurde auch mit Java 8 ausgeführt und dementsprechend sieht man einen ausgeführten Test und zwei weitere Testmethoden, die nicht berücksichtigt wurden:

@CsvSource und @CsvFileSource

Bis jetzt konnte man nur einstellige Trennzeichen bei den Annotationen @CsvSource und @CsvFileSource benutzen. In diesem Release wurden diese Annotationen erweitert, sodass man mehrstellige Trennzeichen sowie benutzerdefinierte Nullwerte verwenden kann.  

Folgendes Codebeispiel zeigt, wie man diese Annotationen benutzen kann:

@TestMethodOrder(OrderAnnotation.class)
public class TestDemo {
	
	@Order(value = 1)
	@ParameterizedTest
	@CsvSource(value = {"JUnit!  5.6!"
			, "Java!8"
			, "'Apache, Spark'! 2.2"}
			, delimiter = '!')
	void checkValuesBySingleDelimiter(String name, double version) {
		assertNotNull(name, version);   
	}
	
	@Order(value = 2)
	@ParameterizedTest
	@CsvSource(value = {"JUnit!!?5.6!!?"
			, "Java!!?8"
			, "'Apache, Spark'!!? 2.2"}
			, delimiterString = "!!?" )
	void checkValuesByMultipleDelimiter(String name, double version) {
	    assertNotNull(name, version);   
	}
}

Hier ist zu sehen, dass die Elemente aus der CSV Datenquelle bei der ersten Methode mit durch ein einzelnes Zeichen (!)  getrennt werden. Dies wird mit dem Attribut delimiter konfiguriert. In der zweiten Methode sieht man die gleiche Datenquelle, jedoch wird mit dem Attribut (delimiterString) festgelegt, dass der Delimiter eine mehrstellige Zeichenkette (!!?) ist.

Wenn man die Attribute nicht explizit definiert, wird als Standardwert für das Trennzeichen ein einfaches Komma verwendet.

An dieser Stelle will ich auf die Verbesserung der Verwendung von Nullwerten in diesem Release eingehen. Bis jetzt musste man einen Umweg finden, um Nullwerte in einer Datenquelle zu übergeben. Unsere Datenquellen durften bisher Nullwerte nicht direkt enthalten.

Folgendes Beispiel beschreibt, wie einfach es nun geworden ist,  Datenquellen mit Nullwerten zu definieren:

@ParameterizedTest
@CsvSource(value = {"JUnit!  5.6!"
		, "Java!8"
		, "'Apache, Spark'! 2.2"
		, "null! 1.7"
		, "N/A! 33"
		, " ! 11"}
		, delimiter = '!'
		, nullValues = {"null", "N/A"})
void checkValuesByNullValue(String name, double version) {
	assertNotNull(name, version);   
}

Hier wurde das neue Attribut nullValues mit den Werten definiert, die als Nullwerte interpretiert werden sollen:

Neben diesen Verbesserungen hat das JUnit-Team die @Order Annotation aktualisiert. Man kann mit dieser Annotation nun die relative Reihenfolge von Testmethoden beim Ausführen festlegen, was bis jetzt nicht möglich war.

Darüber hinaus wurde noch die neue Schnittstelle TestInstancePreDestroyCallbackeingeführt, mit der Test-Instanzen verarbeitet werden können, nachdem sie ausgeführt und bevor sie weggeworfen werden.

Weitere Infos gibt es auf den Release Notes.

Short URL for this post: https://wp.me/p4nxik-3C9
This entry was posted in Java and Quality and tagged . Bookmark the permalink.

Leave a Reply