wenn ich das mache dann kommt 0 raus.
Das ist übrigens ein sehr schönes Beispiel dafür, dass sich die Denkweise beim Test Driven Development völlig ändert. Für Interessierte:
@mrBrown hat hierzu bereits zwei schöne Beispiele gepostet (zu
FizzBuzz und
Pfadsuche), daher erspare ich mir den Code.
Ohne TDD setze ich mich hin und schreibe Code, der das Problem löst. Ich konzentriere mich also auf das Problem. Ganz anders, wenn ich TDD anwende. Dann schaltet mein Hirn in den Test-Mode, d. h. mich interessiert der Code der Methode erstmal gar nicht und schon der Anblick von
public static int ermittleGroessteZahl(int[] array)
löst einen Reflex aus. Ich würde das mal als den
null
-Reflex bezeichnen.
null
ist für den Programmierer die heiße Herdplatte, die man mit den Fingern berührt, der leichter Stromschlag, der einen zusammenzucken lässt. Was also passiert, wenn man der Methdoe
null
übergibt? Oder besser: was soll passieren? Eine NullPointerException wäre angebracht.
Das kann man testen und weiter gehts: was soll passieren, wenn array leer ist? Ooops. Auch hier wäre eine Exception angebracht, denn in einem leeren Array gibt es nun einmal keine größte Zahl. Natürlich ist es keine NPE, eher eine IllegalArgumentException oder NoSuchElementException.
Test geschrieben, weiter gehts: Das array kann null oder leer sein, gut, es kann aber auch genau ein Element enthalten, das dann natürlich auch das größte Element sein muss... Test schreiben und weiter mit zwei Elementen.
Bei zwei Elementen kommt man mit einem if, dem ternären Operator oder auch Math.max aus. Auch den Fall kann man testen, ab drei Elementen muss man sich aber was einfallen lassen: je konkreter der Testcode wird, desto allgemeiner muss der Produktivcode werden.
Beim TDD liegt der Fokus also auf der Spezifikation, das Problem wird eher nebenbei gelöst. Die Aussage ist allerdings mit Vorsicht zu genießen, denn das Problem besteht tatsächlich in der Erfüllung der Spezifikation und nicht im Code, der nur einen Teil, den happy Path, implementiert.