test-driven-development

Test-Driven Development (TDD)

Kurz: Bei TDD schreibt man zuerst einen fehlschlagenden Test, dann gerade so viel Code, dass er besteht, und räumt danach auf. Dieser Zyklus heißt Red – Green – Refactor.

Genauer: TDD zwingt dazu, vor dem Programmieren zu überlegen, was der Code leisten soll. Die Tests dokumentieren das Verhalten, jede Funktion ist testbar entworfen (Dependency Injection hilft), und das spätere Refactoring ist abgesichert.

Im Detail

Der Zyklus

1. Red: Einen kleinen Test schreiben, der (noch) fehlschlägt.
2. Green: Den einfachsten Code schreiben, der den Test bestehen lässt.
3. Refactor: Code aufräumen, ohne dass Tests rot werden.

Beispiel: Fizz-Buzz

# 1. Red
def test_drei_ist_fizz():
    assert fizzbuzz(3) == "Fizz"          # NameError: fizzbuzz existiert nicht
 
# 2. Green
def fizzbuzz(n):
    return "Fizz"
 
# 3. nächster Test (Red)
def test_fuenf_ist_buzz():
    assert fizzbuzz(5) == "Buzz"
 
# Green: Code verallgemeinern
def fizzbuzz(n):
    if n % 15 == 0: return "FizzBuzz"
    if n % 3 == 0:  return "Fizz"
    if n % 5 == 0:  return "Buzz"
    return str(n)

Vor- und Nachteile

Vorteile	Nachteile
wenige Fehler, hohe Testabdeckung	Anfangs langsamer
Code ist modular und testbar	Gute Tests brauchen Übung
Sicherheitsnetz für Änderungen	Bei explorativer Arbeit unpassend

Eng verwandt ist BDD (Behavior-Driven Development), das Tests in lesbarer Fachsprache formuliert (Given/When/Then). Grundlage sind Unit-Tests.

Siehe auch: Unit-Test, Refactoring, Clean Code, Debugging