© Excellent backgrounds/Shutterstock.com
Java Magazin
Data-driven Tests mit TestNG

Drum teste, wer sich bindet


Jede Art von Software verarbeitet Daten. Diese Daten können unterschiedlich strukturiert sein. Es gibt zu verarbeitende Daten, die sich in Äquivalenzklassen einteilen lassen. Tests dafür zu schreiben, kann mühselig sein. TestNG hilft dabei, datengetriebene Tests einfach umzusetzen. Aber auch da gibt es einen Knackpunkt: die externe Datenquelle.

Ein Beispiel für Daten, die sich in Äquivalenzklassen einteilen lassen, sind mögliche Testdaten für die Funktion isBetween(int value, int lowerBound, int upperBound). Diese Funktion prüft, ob ein Wert value zwischen den einschließenden Intervallgrenzen lowerBound und upperBound liegt. Wenn wir z. B. für die Variable low­er­Bound den Wert auf 5 festsetzen und den Wert der Variablen upperBound auf 10, gibt es für die Variable value Werte in fünf Äquivalenzklassen. Diese sind für alle Werte x:

  • x < 5

  • x == 5

  • x > 5 && x < 10

  • x == 10

  • x > 10

Um die korrekte Funktionsweise der Funktion isBetween in allen fünf möglichen Fällen sicherzustellen, benötigen wir fünf Aufrufe der Funktion mit jeweils einem Wert aus einer der Äquivalenzklassen für die Variable value.

Schauen wir uns zunächst an, wie wir dieses Szenario mit JUnit umsetzen könnten. Ohne einen speziellen Test Runner stehen uns zwei Optionen zur Verfügung. Erstens könnten wir fünf verschiedene Testmethoden in einer Testklasse anlegen. Jede Testmethode würde dann die Funktion isBetween mit einem anderen Wert für die Variable value aufrufen. Diese Herangehensweise wäre in diesem speziellen Fall vielleicht gerade noch akzeptabel. Wenn wir allerdings komplexere Testfälle mit mehreren Variablen und vielen Äquivalenzklassen und deren Kombinationen auf diese Art und Weise implementieren wollen würden, würden unsere Testklassen schnell unübersichtlich. Sie würden auch viel duplizierten Code enthalten, da sich nur die Daten, nicht aber die zu testenden Methodenaufrufe ändern. Ganz ähnlich sieht es mit der zweiten Option aus: dem Parameterized-Test-Case-Pattern. Hierbei wird die Testmethode lediglich einmal implementiert und die veränderlichen Testdaten werden per Konstruktor an die Klasse übergeben. Damit duplizieren wir weniger Code. Sollten wir allerdings mehrere Testmethoden mit jeweils mehreren voneinander unabhängigen Parametern in einer solchen Testklasse unterbringen, geht auch in diesem Fall die Übersichtlichkeit schnell verloren. Ebenso fehlt eine logische Trennung der verschiedenen Testmethoden, da jede Testmethode Zugriff auf alle mittels Konstruktor übergebenen P...

Java Magazin
Data-driven Tests mit TestNG

Drum teste, wer sich bindet

Jede Art von Software verarbeitet Daten. Diese Daten können unterschiedlich strukturiert sein. Es gibt zu verarbeitende Daten, die sich in Äquivalenzklassen einteilen lassen. Tests dafür zu schreiben, kann mühselig sein. TestNG hilft dabei, datengetriebene Tests einfach umzusetzen. Aber auch da gibt es einen Knackpunkt: die externe Datenquelle.

Matthias Rothe


Jede Art von Software verarbeitet Daten. Diese Daten können unterschiedlich strukturiert sein. Es gibt zu verarbeitende Daten, die sich in Äquivalenzklassen einteilen lassen. Tests dafür zu schreiben, kann mühselig sein. TestNG hilft dabei, datengetriebene Tests einfach umzusetzen. Aber auch da gibt es einen Knackpunkt: die externe Datenquelle.

Ein Beispiel für Daten, die sich in Äquivalenzklassen einteilen lassen, sind mögliche Testdaten für die Funktion isBetween(int value, int lowerBound, int upperBound). Diese Funktion prüft, ob ein Wert value zwischen den einschließenden Intervallgrenzen lowerBound und upperBound liegt. Wenn wir z. B. für die Variable low­er­Bound den Wert auf 5 festsetzen und den Wert der Variablen upperBound auf 10, gibt es für die Variable value Werte in fünf Äquivalenzklassen. Diese sind für alle Werte x:

  • x < 5

  • x == 5

  • x > 5 && x < 10

  • x == 10

  • x > 10

Um die korrekte Funktionsweise der Funktion isBetween in allen fünf möglichen Fällen sicherzustellen, benötigen wir fünf Aufrufe der Funktion mit jeweils einem Wert aus einer der Äquivalenzklassen für die Variable value.

Schauen wir uns zunächst an, wie wir dieses Szenario mit JUnit umsetzen könnten. Ohne einen speziellen Test Runner stehen uns zwei Optionen zur Verfügung. Erstens könnten wir fünf verschiedene Testmethoden in einer Testklasse anlegen. Jede Testmethode würde dann die Funktion isBetween mit einem anderen Wert für die Variable value aufrufen. Diese Herangehensweise wäre in diesem speziellen Fall vielleicht gerade noch akzeptabel. Wenn wir allerdings komplexere Testfälle mit mehreren Variablen und vielen Äquivalenzklassen und deren Kombinationen auf diese Art und Weise implementieren wollen würden, würden unsere Testklassen schnell unübersichtlich. Sie würden auch viel duplizierten Code enthalten, da sich nur die Daten, nicht aber die zu testenden Methodenaufrufe ändern. Ganz ähnlich sieht es mit der zweiten Option aus: dem Parameterized-Test-Case-Pattern. Hierbei wird die Testmethode lediglich einmal implementiert und die veränderlichen Testdaten werden per Konstruktor an die Klasse übergeben. Damit duplizieren wir weniger Code. Sollten wir allerdings mehrere Testmethoden mit jeweils mehreren voneinander unabhängigen Parametern in einer solchen Testklasse unterbringen, geht auch in diesem Fall die Übersichtlichkeit schnell verloren. Ebenso fehlt eine logische Trennung der verschiedenen Testmethoden, da jede Testmethode Zugriff auf alle mittels Konstruktor übergebenen P...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang