Grundlagen des Unit-Testings

Wir haben uns in der Vergangenheit schon mit verschiedenen Aspekten des Themas “Testing” beschäftigt. Nun ist es an der Zeit tiefer einzutauchen, es ist Zeit sich die Hände dreckig zu machen. Ran an den Speck Code!

Ich lasse euch daran teilhaben, wie ich Unit-Tests angehe, ohne den Anspruch absoluter Wahrheit oder Perfektion. Was folgt, sind keine Regeln und keine Anleitung. Es ist eine Beschreibung dessen, was für mich gut funktioniert. Spoiler: Das ist nicht (immer) Test-driven Development (TDD) und ich folge auch weder (immer) den “Regeln” oder Empfehlungen von Robert “Uncle Bob” Martin noch dem “One Assertion per Test”-Paradigma. Ich denke, ich folge einem pragmatischen Mittelweg, und die Erfahrung von Rob Martin, die er in “Just 10 minutes without a test” beschreibt, kann ich nachempfinden. Es ist immer ein ungutes Gefühl beispielsweise morgens im Daily Scrum zu sagen: “Das Feature ist fertig. Ich schreibe heute nur noch die Unit-Tests dafür”.

Versteht mich nicht falsch, jede(r) hat sicher einen für sich persönlich gut funktionierenden Weg. Dieser ist eben nur nicht meiner. Und müssen wir immer alle dem gleichen Weg folgen? Ich glaube nicht. Viel wichtiger ist, dass wir uns in einem Punkt einig sind: Tests sind wichtig! Unit-Tests sind besonders wichtig!

Meine Grundannahme bei Unit-Tests ist praktisch Murphy’s Law: Alles, was schiefgehen kann, wird auch irgendwann irgendwie irgendwo unter irgendwelchen Umständen schiefgehen. Wir alle kennen sicher die “This should never happen”-Fälle, die wir in unserem Code vorsehen, zum Beispiel beim Fangen von Exceptions. Und dann treten diese Fälle doch ein und wir wundern uns.

Deshalb ist mein Fazit aus Murphy’s Law für die Unit-Tests: Alles, was sinnvoll getestet werden kann, wird auch getestet. Doch was bedeutet hier sinnvoll? Streben wir 100 Prozent Testabdeckung an? Ich strebe eine hohe Testabdeckung relevanter Code-Teile an und achte auch in Reviews darauf. Ein paar Überlegungen dazu gab es auch schon einmal in einem früheren Artikel.

Genug der Vorrede. Wie gehe ich das denn nun im Detail an?

Photo by Corinne Kutz on Unsplash

Beispiel: ein einfacher Taschenrechner

Als Test-Objekt nehmen wir eine einfache Java-Klasse Calculator, die mit der Methode calculate() einfache Grundrechenarten verarbeiten kann. Als Eingabe wird ein String verwendet, der per Regular Expression in die Operanden und den Operator aufgeteilt wird, bevor die eigentliche Berechnung ausgeführt wird:

package de.pentacor.blog.unittesting;

import java.util.regex.Pattern;

public class Calculator {

  private static final String CALCULATION_REGEX = "^(?<a>\\d+)\\s*(?<operator>[+\\-\\*/])\\s*(?<b>\\d+)$";
  private static final Pattern CALCULATION_PATTERN = Pattern.compile(CALCULATION_REGEX);

  public Double calculate(String calculation) {
    var matcher = CALCULATION_PATTERN.matcher(calculation);

    if (matcher.find()) {
      var operator = matcher.group("operator");
      var a = Double.valueOf(matcher.group("a"));
      var b = Double.valueOf(matcher.group("b"));

      return switch (operator) {
        case "+" -> a + b;
        case "-" -> a - b;
        case "*" -> a * b;
        case "/" -> a / b;
      };
    }

    throw new IllegalArgumentException("Invalid calculation: " + calculation);
  }
}

Das ist kein kompliziertes Beispiel und doch ist hier schon einiges los. Und wo was los ist, kann auch was schiefgehen. Was sollten wir also testen?

• dass die Operanden korrekt aus der Eingabe extrahiert werden
• dass der Operator korrekt aus der Eingabe extrahiert wird
• dass die Grundrechenarten korrekt ausgeführt werden
• dass uns nicht alles um die Ohren fliegt, wenn die Eingabe irgendwie “unerwartet” ist

So, wie das Beispiel momentan geschrieben ist, sind unsere Möglichkeiten, diese verschiedenen Dinge unabhängig zu testen, beschränkt, denn wir haben nur eine einzige Methode, die alles macht. Also müssten die Unit-Tests für diese eine Methode auch alles abdecken. So richtig spaßig klingt das jetzt nicht, zumal ein regulärer Ausdruck involviert ist – und damit wird es doch eigentlich immer interessant. Und stellen wir uns nur mal vor, was erst noch los wäre, wenn wir auch noch externe Abhängigkeiten hätten, die in dieser Methode verwendet werden …

Code überhaupt erst (sinnvoll) testbar machen

Die bereitgestellte, extern genutzte Funktionalität kann beliebig komplex sein. Das spricht für ebenso komplexe Tests. Meh. Ich hätte es doch gern einfach …

Überarbeiten wir also die Calculator-Klasse, um uns das Leben einfacher zu machen und verschiedene Dinge separat testen zu können.

Aufteilung in feingranulare Methoden

Nur weil ich einzelne Teile separat testen können will, möchte ich sie aber nicht gleichzeitig auch separat nutzbar haben. Dazu schränke ich also die Sichtbarkeit der Methoden entsprechend ein:

• public – und damit von überall aufrufbar – bleibt nur die Methode calculate().
• Alle anderen Methoden werden private und können damit bekanntermaßen nur von der Klasse selbst verwendet werden.

Das Ergebnis dieses Refactorings sieht dann wie folgt aus:

package de.pentacor.blog.unittesting;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Calculator {

  private static final String CALCULATION_REGEX = "^(?<a>\\d+)\\s*(?<operator>[+\\-\\*/])\\s*(?<b>\\d+)$";
  private static final Pattern CALCULATION_PATTERN = Pattern.compile(CALCULATION_REGEX);

  public Double calculate(String calculation) {
    var operator = extractOperator(calculation);
    var a = extractOperand(calculation, "a");
    var b = extractOperand(calculation, "b");

    return switch (operator) {
      case "+" -> add(a, b);
      case "-" -> subtract(a, b);
      case "*" -> multiply(a, b);
      case "/" -> divide(a, b);
      default -> throw new IllegalArgumentException("Invalid calculation: " + calculation);
    };
  }

  private Double extractOperand(String calculation, String operand) {
    return Double.valueOf(extractNamedGroupFrom(calculation, operand));
  }

  private String extractOperator(String calculation) {
    return extractNamedGroupFrom(calculation, "operator");
  }

  private String extractNamedGroupFrom(String calculation, String groupName) {
    Matcher matcher = CALCULATION_PATTERN.matcher(calculation);
    if (matcher.find()) {
      return matcher.group(groupName);
    }
    return null;
  }

  private double add(Double a, Double b) {
    return a + b;
  }

  private double subtract(Double a, Double b) {
    return a - b;
  }

  private double multiply(Double a, Double b) {
    return a * b;
  }

  private double divide(Double a, Double b) {
    return a / b;
  }
}

Die öffentliche Methode ist in erster Linie diejenige, die die wesentliche Funktionalität meiner Klasse bereitstellt. Dass diese getestet werden (muss), versteht sich von selbst. Da sie öffentlich sichtbar ist und von überall verwendet werden kann, ist das auch kein Problem. Die Herausforderung steckt jetzt allerdings im Detail, im wahrsten Sinne des Wortes.

Die privaten Methoden kapseln die Einzelteile der Funktionalität in kleine, einfach zu verstehende Units. Und was einfach zu verstehen ist, ist auch einfach zu testen. Das soll uns jedoch nur intern helfen und nicht von außen verwendet werden, schließlich wollen wir unsere Abhängigkeiten unter Kontrolle halten. Entsprechend sind die Methoden nicht nur gekapselt, sondern auch verborgen.

Problem gelöst! Ja, jetzt kommt wirklich keiner mehr ran. Auch nicht unser Test, der schließlich in einer separaten Klasse im Verzeichnis src/test/java im gleichen Package implementiert ist. Doof.

Für einen Test der öffentlich sichtbaren Methode calculate() ist das jedoch zunächst kein Problem. Ein beispielhafter Unit-Test könnte so aussehen:

@Test
void calculate_withAddition_returnsExpectedResult() {
  // arrange
  Calculator calculator = new Calculator();
  String input = "2 + 3";
  Double expectedResult = 5d;

  // act
  Double result = calculator.calculate(input);

  // assert
  assertNotNull(result);
  assertEquals(expectedResult, result);
}

Methoden für den Test zugänglich machen

Für eine private Methode sieht das Bild allerdings gleich ganz anders aus. Da müssen wir erst einmal eine Möglichkeit bekommen, auf die Methode zuzugreifen.

Reflections to the rescue! Java bietet ja die Möglichkeit, über Reflections auf Klassen und Methoden zuzugreifen, die Sichtbarkeit zu verändern und sie dann auszuführen und so in unseren Unit-Tests zugänglich zu machen … Problem wieder gelöst!

@Test
void add_withValidOperands_returnsExpectedResult()
    throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
  // arrange
  Double a = 2d;
  Double b = 3d;
  Double expectedResult = 5d; 

  Method add = Calculator.class.getDeclaredMethod("add", Double.class, Double.class);
  add.setAccessible(true); 

  // act
  Double result = (Double) add.invoke(calculator, a, b); 

  // assert
  assertNotNull(result);
  assertEquals(expectedResult, result);
}

Bevor wir die Methode add() testen können, müssen wir uns erst einmal Zugang verschaffen und die Methode ausführbar machen, bevor wir sie ebenfalls über Reflections ausführen, auf der vorher bereits verwendeten Instanz calculator. Leider sind die Reflections nicht generisch, sodass wir das Ergebnis erst noch auf den gewünschten Typ casten müssen. Allein durch die Verwendung von Reflections könnte dieser ziemlich simple Test (theoretisch) also schon mal drei verschiedene Exceptions werfen, die deklariert werden müssen, ganz zu schweigen von möglichen Runtime Exceptions, wie beispielsweise einer Exception beim Cast von Object auf Double.

Natürlich, das sind vergleichsweise künstliche Überlegungen, die nicht eintreten sollten. “This should never happen.” Moment, da war doch was … Murphy’s Law. Was schiefgehen kann, wird auch schiefgehen. Ich würde mich besser fühlen, wenn ich die Komplexität der Reflections aus meinen Tests verbannen kann.

Meine Lösung: Ich nutze die Standard-Sichtbarkeit der Methoden, entferne also den Modifier private. Damit sind sie aus dem gleichen Package wie dem der implementierenden Klasse erreichbar und unser beispielhafter Test kann deutlich vereinfacht werden:

@Test
void add_withValidOperands_returnsExpectedResult() {
  // arrange
  Double a = 2d;
  Double b = 3d;
  Double expectedResult = 5d; 

  // act
  Double result = calculator.add(a, b); 

  // assert
  assertNotNull(result);
  assertEquals(expectedResult, result);
}

Sollten jetzt noch Exceptions geworfen werden, kommen sie aus der Methode, die ich testen möchte, also aus der Business-Logik statt aus der Test-Implementierung.

Anatomie eines Unit-Tests

In den Beispielen der Testfälle sind einige der Konventionen zu sehen, die ich beim Schreiben meiner Unit-Tests befolge:

Name der Test-Methode

Die Namen meiner Testfälle, also Test-Methoden, haben drei separate Teile, die jeweils mit _ separiert sind:

1. der Name der getesteten Methode: add
2. die Testbedingung, also eine knappe Beschreibung des Testfalls: withValidOperands
3. das erwartete Ergebnis: returnsExpectedResult

Daraus ergibt sich eine einigermaßen gut lesbare und sprechende Beschreibung des Testfalls. Je nach Methode, Bedingung und erwartetem Ergebnis kann das allerdings zu (für Java nicht untypischen) extrem langen Methodennamen führen, doch dazu später mehr.

Arrange-Act-Assert-Pattern

Ich bin ein Freund des Arrange-Act-Assert-Patterns, das es ermöglicht, Testfälle durch einfache Kommentare klar zu strukturieren und in Abschnitte zu unterteilen:

Naturgemäß sind die Abschnitte Arrange und Assert länger als Act. In vielen Fällen ist Arrange der vermutlich längste, gerade wenn viel Vorbereitung erforderlich ist, weil die Eingaben oder erwarteten Ergebnisse sehr komplex sind, viel gemockt werden muss usw. In diesen Fällen bietet sich die Frage an, ob beim Test-Code das gleiche Vorgehen wie beim produktiven Code angewendet werden kann und sollte: Lassen sich Teile in eigene (Hilfs-) Methoden auslagern?

Habe ich dagegen sehr viele Assertions in meinem Testfall, sollte ich mich eher fragen, ob ich vielleicht versuche zu viele Dinge auf einmal zu testen. Wäre es unter Umständen besser, meinen Testfall in mehrere kleinere Testfälle aufzuteilen, die jeweils die Assertions für einen Teil-Aspekt enthalten? Wovon ich in diesem Zusammenhang kein Freund bin: Hilfsfunktionen für Assertions à la checkResult() zu schreiben, die dann wiederum alle Assertions enthalten und potenziell in verschiedenen Tests immer wieder verwendet werden.

Unit-Tests haben normalerweise den großen Vorteil, dass sie Methoden durch beispielhafte Ausführung “dokumentieren” – das wird durch Auslagerung von Assertions in (intransparente) separate Methoden erheblich erschwert. Das gleiche gilt übrigens, wenn die unter Arrange verwendeten Eingaben zu größten Teilen aus woanders definierten Variablen und Konstanten herangezogen werden.

Das richtige Maß zu finden, ist also in vielen Fällen eine Gratwanderung. Persönlich nehme ich allerdings eher Redundanz in Kauf und habe dafür einen Test, bei dem ich Eingabe und Ausgabe auf einen Blick erkennen kann, ohne dass ich dafür noch in sechs weitere Dateien schauen und zu drei anderen Methoden scrollen muss.

Wo wir gerade beim Thema Übersichtlichkeit und Erfassen von Tests auf einen Blick sind: In manchen Fällen fasse ich die Abschnitte Act und Assert auch zusammen, also insbesondere dann, wenn die Assertion es erfordert, dass der Aufruf der getesteten Funktion innerhalb der Assertion erfolgt:

@Test
void calculate_withInvalidInput_throwsException() {
  // arrange
  Calculator calculator = new Calculator();
  String input = "foo bar";

  // act & assert
  assertThrows(IllegalArgumentException.class, () -> calculator.calculate(input));
}

Würde ich krampfhaft an der vorherigen dreiteiligen Struktur festhalten wollen, müsste ich den Testfall so schreiben:

@Test
void calculate_withInvalidInput_throwsException() {
  // arrange
  Calculator calculator = new Calculator();
  String input = "foo bar";

  // act
  Executable methodCall = () -> calculator.calculate(input);

  // assert
  assertThrows(IllegalArgumentException.class, methodCall);
}

Das ist zwar möglich, doch aus meiner Sicht sinnlos. Eine mögliche Ausnahme: Der zu testende Methoden-Aufruf hat sehr viele Argumente, ist irgendwie unübersichtlich oder aus anderen Gründen komplex. Selbst in diesem Fall liegen Problem und Lösung allerdings sehr wahrscheinlich woanders.

Was ich in den meisten Fällen auch nicht mache: Tests auf eine Zeile reduzieren. So gern ich meinen produktiven Code knapp halte und nach Möglichkeit auf wenige Zeilen reduziere, so gern halte ich der Konsistenz und Lesbarkeit wegen am Arrange-Act-Assert-Pattern fest. Doch urteilt selbst, ob euch dieser Test besser gefällt als die vorherigen Beispiele:

@Test
void calculate_withAddition_returnsResult() {
  assertEquals(5, calculator.calculate("2 + 3"));
}

Test-Klassen-Organisation

Je nachdem, wie viel Funktionalität und Komplexität in einer Klasse steckt und wie viele verschiedene Testfälle es abzudecken gilt, kann eine Test-Klasse schnell ziemlich lang und unübersichtlich werden.

Da könnte man jetzt beispielsweise anfangen, mehre Test-Klassen für eine einzelne “Produktiv-Klasse” zu schreiben. Der Gedanke überzeugt mich jedoch nicht. CalculatorTest als Test für Calculator ist logisch und naheliegend. Was mache ich aber, wenn ich einzelne Klassen für die Tests einzelner Methoden schreiben will? Ende ich dann mit einem solchen Konstrukt?

• AbstractCalculatorTest als abstrakte Parent-Klasse für alle einzelnen Klassen für die gemeinsame Initialisierung und Vorbereitung der Tests insgesamt
• CalculateCalculatorTest für Tests der Funktion calculate()
• AddCalculatorTest für Tests der Funktion add()
• …

Oder müsste ich die einzelnen Klassen nicht eher so benennen, dass Calculator vorn steht und alphabetisch sortiert die Tests einzelner Methoden einer Klasse zusammen?

• CalculatorAbstractTest
• CalculatorAddTest
• CalculatorCalculateTest
• …

Naming – eines der schwierigsten Probleme. Man kennt es.

Nein, was ich stattdessen mache, ist ein IDE-Feature zu nutzen: IntellIJ IDEA erlaubt es, mittels Kommentaren im Code Regionen zu definieren, die dann zusammengeklappt werden können. Damit würde eine Test-Klasse insgesamt etwa so aussehen:

package de.pentacor.blog.unittesting;

import static org.junit.jupiter.api.Assertions.*;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;

class CalculatorTest {

  Calculator calculator = new Calculator();

  // region calculate()

  @Test
  void calculate_withAddition_returnsResult() {
    // arrange
    String input = "2 + 3";
    Double expectedResult = 5d;

    // act
    Double result = calculator.calculate(input);

    // assert
    assertNotNull(result);
    assertEquals(expectedResult, result);
  }

  @Test
  void calculate_withInvalidInput_throwsException() {
    // arrange
    String input = "foo bar";

    // act
    Executable methodCall = () -> calculator.calculate(input);

    // assert
    assertThrows(IllegalArgumentException.class, methodCall);
  }
  
  // endregion
  
  // region add()

  @Test
  void add_withValidOperands_returnsResult() {
    // arrange
    Double a = 2d;
    Double b = 3d;
    Double expectedResult = 5d;

    // act
    Double result = calculator.add(a, b);

    // assert
    assertNotNull(result);
    assertEquals(expectedResult, result);
  }
  
  // endregion
}

Die Regionen oder Abschnitte können auch beliebig ineinander verschachtelt werden, so dass sie eine gute Möglichkeit bieten, lange Source Files zu strukturieren und zu organisieren. Das funktioniert übrigens auch in beliebigen anderen Dateiformaten, wie beispielsweise YAML oder SQL, und ist damit eine unbedingte Empfehlung.

Auswahl von Testfällen

Wir haben jetzt gesehen, wie ich meine Tests grundsätzlich schreibe und ich hatte anfangs auch angedeutet, alle denkbaren Fälle abdecken zu wollen. Das bedeutet insbesondere:

• Eingabewert null für alle Argumente einer Methode
• leere Eingabewerte für alle Argumente einer Methode, also insbesondere "", Collections.emptyList() usw.
• ungültige Eingabewerte
• gültige Eingabewerte für den Happy Path (natürlich)

Auf den ersten Blick scheint das, auch schon mit Blick auf das Beispiel der Klasse Calculator, nicht notwendig zu sein, denn der als Eingabe verwendete String muss ja am regulären Ausdruck für die Rechnung vorbei. Und eben dieser Ausdruck ^(?<a>\d+)\s*(?<operator>[+\-\*/])\s*(?<b>\d+)$ sieht vor:

• Der String beginnt mit einer Zahl bestehend aus mindestens einer Ziffer.
• Auf den ersten Operanden a folgt eine beliebige Zahl an Leerzeichen.
• Es folgt der Operator, der entweder +, -, * oder / ist.
• Auf den Operator folgt wieder eine beliebige Zahl an Leerzeichen.
• Der String endet schließlich mit einer Zahl bestehend aus mindestens einer Ziffer.

Was sollte also schiefgehen?

In der allerersten Version des Rechners konnte zugegebenermaßen tatsächlich noch gar nicht so viel passieren. Einige Probleme haben wir erst durch das Aufteilen der Funktionalität in separate Funktionen eingeführt (ironischerweise): Dadurch, dass die Extraktion des Operators aus dem String und seine anschließende Auswertung jetzt in unterschiedlichen Kontexten stattfinden – also insbesondere das switch-Statement unabhängig von einem Match der Eingabe auf den regulären Ausdruck ausgeführt wird –, haben wir uns plötzlich das sehr reale Risiko einer NullpointerException in den Code geholt. Diese fällt auf, wenn wir die Methode calculate() mit einer ungültigen Eingabe aufrufen.

Zur Lösung des Problems gibt es verschiedene Möglichkeiten, die wiederum an verschiedenen Stellen getestet werden können. Beispielsweise könnte die neue Methode extractOperator() direkt eine Exception werfen, wenn kein gültiger Operator aus der Eingabe extrahiert werden kann. Oder die Funktion calculate() wird um einen zusätzlichen Null-Check erweitert. Darum soll es jetzt jedoch gar nicht im Detail gehen.

Viel wichtiger ist es, im Hinterkopf zu behalten, dass Methoden immer auch mit eigentlich (aktuell) “nicht möglichen” Bedingungen getestet werden sollten, um spätere Überraschungen zu vermeiden. Wie wir gesehen haben, können die schon durch einfache Refactorings schnell und leicht entstehen.

Und denken wir noch ein Stück weiter: Wir haben auch die Methoden für die Ausführung der eigentlichen Berechnungen als private Methoden extrahiert. An der Stelle könnte man durchaus darüber diskutieren, ob die nicht auch public sein könnten oder sollten, schließlich ergibt das für einen Rechner durchaus Sinn. Es gibt nicht unbedingt einen nachvollziehbaren Grund sie zu verstecken, außer: Die vormals allein intern verwendeten Methoden könnten nun von gänzlich anderen, potenziell unbekannten Stellen verwendet werden, auf unklare Weise, mit möglicherweise ungültigen Eingabewerten. Diese ungültigen und unerwarteten Eingaben führen dann zu unerwarteten Fehlern, wenn wir uns nicht vorher bei der Auswahl unserer Test Cases schon auf alle Eventualitäten vorbereitet haben.

Haben wir das am Anfang versäumt, wird es später deutlich schwieriger. Daher ist es auch unerlässlich, beim Auftreten von Bugs unbedingt erst einmal einen Test zu schreiben, der den Bug reproduziert, bevor er gefixt wird. Das erhöht auf Dauer definitiv die Sicherheit und Robustheit der Anwendung, auch im Blick auf künftige Refactorings.

Parametrisierte Tests

Häufig ist es so, dass viele Tests sich eigentlich nur in ihren Eingaben unterscheiden, aber das gleiche Ergebnis erwarten oder die Ausführung des Tests im Prinzip identisch ist und der Tests sozusagen eine Funktion f (Eingabe, Ausgabe) ist. In diesen Fällen macht uns JUnit 5 mit der Test-Annotation @ParameterizedTest das Leben um ein Vielfaches leichter, denn wir brauchen den grundsätzlichen Test nur einmal zu definieren und können ihn dann beliebig oft mit verschiedensten Parametern ausführen.

Welche Parameter verwendet werden, hängt dabei von weiteren Annotations ab. Am einfachsten ist @NullSource – damit wird dem Test einfach nur null als Parameter übergeben. Zugegeben, das ist für sich allein genommen nicht supersinnvoll, in Kombination mit @ValueSource dagegen schon sehr viel mehr. Schauen wir uns ein Beispiel an:

@ParameterizedTest
@NullSource
@ValueSource(doubles = {0d, 1d, 2d, 3d, 4d})
void add_withParameters_returnsExpectedResult(Double a) {
  // arrange
  Double b = 1d;
  Double expectedResult = a != null ? a + b : b;

  // act
  Double result = calculator.add(a, b);

  // assert
  assertEquals(expectedResult, result);
}

@ParameterizedTest
@MethodSource("add_params")
void add_withParameters_returnsExpectedResult(Double a, Double b, Double expectedResult) {
  // act
  Double result = calculator.add(a, b);

  // assert
  assertEquals(expectedResult, result);
}

static Stream<Arguments> add_params() {
  return Stream.of(
    Arguments.of(null, null, 0d),
    Arguments.of(1d, null, 1d),
    Arguments.of(null, 1d, 1d),
    Arguments.of(2d, 3d, 5d),
    Arguments.of(23d, 6d, 29d),
    Arguments.of(1200d, 34d, 1234d)
  );
}

@DisplayName("Calculator.add() - Happy Cases")
@ParameterizedTest(name = "Case {index}: {0} + {1} = {2}")
@MethodSource("add_params")
void add_withParameters_returnsExpectedResult(Double a, Double b, Double expectedResult) {
  // act
  Double result = calculator.add(a, b);

  // assert
  assertEquals(expectedResult, result);
}