Und jetzt fügen wir alles zusammen

Wie gesagt würden wir in der Praxis nur jeweils einen einzigen Fehler einbauen. Der Einfachheit halber fassen wir aber alle zusammen:

public int add(final String numbers) {
  double returnValue = 0;
  String[] numbersArray = numbers.split(",");
  if (numbersArray.length == 3) {
    throw new RuntimeException("Up to 2 numbers separated by comma (,) are allowed");
  }
  for (String number : numbersArray) {
    if (number.isEmpty()) { return 0; }
    returnValue += Double.parseDouble(number);
  }
  return (int) returnValue;
}

Erstaunlicherweise ist nicht ein einziger Test fehlgeschlagen! Jeder einzelne vom Autor geschriebene Test ist immer noch grün, obwohl wir in jede zweite Zeile plausible Fehler eingebaut haben. Das zeigt, dass die Testsuite folgende Lücken hat:

1. Sie testet nicht auf Leerzeichen.

2. Sie testet nicht auf tatsächliche leere Substrings/Leerzeichen-Substrings, wo eigentlich eine Zahl stehen sollte.

3. Sie testet nicht auf eine beliebige Anzahl von Eingaben.

4. Es wird nicht auf numerische, nicht-ganzzahlige Eingaben getestet.

Sobald Sie die oben genannten Lücken identifiziert haben, können Sie zudem anfangen, sie zu schließen, indem Sie weitere Tests hinzufügen. Tests, die jetzt fehlschlagen, aber bestehen, sobald Sie alle eingebauten Fehler beheben:

@Test(expected = NumberFormatException.class)
public void doubleInputProvided_shouldThrowException() {
  EXAMPLE.add("1.5,1.5");
}
 
@Test
public void blankString_shouldReturn0() {
  Assert.assertEquals(0, EXAMPLE.add(" "));
}
 
@Test
public void emptyStringAfterNumbers_shouldIgnoreIt() {
  Assert.assertEquals(1, EXAMPLE.add("1, "));
}
 
@Test
public void arbitrarilyManyNumbersProvided_shouldThrowException() {
  StringBuilder inputs = new StringBuilder("3,4");
  for (int i=0; i<10; i++) {
    inputs.append("," + ThreadLocalRandom.current().nextInt());
    try {
      int result = EXAMPLE.add(inputs.toString());
      Assert.fail("No exception thrown. Got result: " + result + ", for input: " + inputs.toString());
    } catch (RuntimeException e) {
      Assert.assertEquals("Up to 2 numbers separated by comma (,) are allowed", e.getMessage());
    }
  }
}

Um es klar zu sagen - die obigen Tests sind sicher nicht perfekt. Mit weiteren Iterationen von mutationsgetriebenen Tests können Sie noch mehr Abdeckungslücken identifizieren, die von den obigen Tests übersehen werden. Außerdem sollten Sie ausgefeiltere Testtechniken verwenden (die hier besprochen werden), um Ihre Testabdeckung auf sinnvolle Weise zu verbessern.

Zumindest aber hilft uns dieser Prozess, besser zu verstehen, wo die Abdeckungslücken sind, und bringt uns der Beseitigung der eklatantesten Lücken näher.

Aber: Ist es das wert?

Zugegeben, das Durchlaufen des obigen Prozesses wird zusätzlichen Aufwand und Zeit erfordern. Und das Endergebnis wird eine viel umfangreichere Serie von Tests sein, von denen viele für ein ungeschultes Auge überflüssig erscheinen mögen. Ist es das also wirklich wert?

Wie immer hängt es von Ihren Prioritäten ab. Wenn Sie quick and dirty einen Prototyp bauen und es Ihnen nichts ausmacht, dass einige kleine und seltene Fehler durchrutschen, ist das wahrscheinlich in Ordnung. Wenn Sie aber Angst vor Produktionsfehlern haben, sollten Sie unbedingt Zeit und Mühe in die Verbesserung Ihrer Testsuite investieren. Eine solide Testsuite mit minimalen Abdeckungslücken ist die beste Verteidigung gegen Produktionsbugs. Auf lange Sicht wird das Ihre Entwicklungsgeschwindigkeit sogar erhöhen, weil es erlaubt, sicher zu refaktorisieren und Änderungen schnell zu verteilen, ohne viel Zeit für manuelle Tests zu verwenden.

Oft wird über TDD gesprochen, als ob es ein Allheilmittel wäre, welches das Problem mit dem Testen "löst". Das ist ganz klar nicht der Fall. Wenn Sie Jeff Dean oder Sanjay Ghemawat sind, können Sie vielleicht eine perfekte Testsuite allein durch Nachdenken schreiben. Für den Rest von uns Sterblichen ist jedoch der beste Weg, Abdeckungslücken in unserer Testsuite zu identifizieren und zu beheben, indem wir sie empirisch testen.