Nehmen wir ein Beispiel:

Ich möchte das BADI in der Bestellung testen, bei dem man Absender, Empfänger und Text einer Bestell-Mail ändern kann.

Ich implementiere dazu das Interface auch in die Testklasse, um die implementierende Klasse zu testen.

Am Ende habe ich dann eine Mail ohne Anhang, da der Test NICHT aus der Bestellung erfolgt.

Dafür lässt sich gut testen, ob Senden an sich funktioniert.

Aber wie ist das mit der Optik des Formulars? Entspricht die fertige PDF der Druckansicht? Sieht das gar am Ende ein klein wenig anders aus wie eine gedruckte Ausgabe?

Hier muss dann im Testsystem das implementierte BADI vom End-User getestet werden, gerne mit ein paar mehr Test-Bestellungen (eine Position, mehrere Positionen, verschiedene Positionstypen, diverse einzubindende Texte, ...)

Eure

Oma Erika

ich glaube, dass sich diese TDD-Methode eher für für komplette Neuentwicklung anwenden lässt.

Wenn man irgendwo an einem bestehenden Prozess einen Badi oder eine neue Klasse oder so was anflanscht, ist das eine Änderung eines bestehenden Prozesses.

Dieser MUSS dann zwingend mit echten Anwendungsfällen und zusätzlich auch vom Anwender getestet werden.

Kein Entwickler kann alle Gedankengänge und Methoden der Endanwender nachbilden.

Natürlich nicht im Produktivsystem, aber zumindest in einer Testumgebung, die mit der Anpassung bzw. Implementierung versorgt wurde.