Hi,

Schreibt man einzelne Funktionen, mag das ja noch gut gehen.
Genau, jede wird zunächst isoliert für sich getestet: Liefert sie für alle erlaubten Argumente das gewünschte Ergebnis?
Da fängt es ja schon an. Manchmal ist das "gewünschte Ergebnis" zwar eben dieses, aber trotzdem logisch falsch.

ähm, nein. Nicht, wenn die Anforderung klar definiert ist.

[...] Da aber, wie du schon andeutest, oft der Teufel im Detail steckt, wird diese Ebene natürlich auch wieder getestet
Und jetzt stell dir vor du hast 100 dieser Ebenen.

Das bedeutet einen Riesenaufwand, den ich aber für unumgänglich halte. Okay, bei umfangreichen Projekten mag es sinnvoll sein, die Tests auf eine Menge von Stichproben zu beschränken, die man vorher sorgfältig auswählt. Aber das bringt natürlich eine gewisse Unsicherheit ins Spiel.

Und nun stell dir vor, es soll sich grundlegend etwas ändern (Kunden...) und du musst die Struktur und die Zusammensetzung/Kombination der Module ändern.

Wenn irgendwo tief im Innern das ausführlich getestete Modul X gegen das ebenfalls ausführlich getestete Modul U getauscht werden soll, ist das IMO ohne großen Aufwand möglich, wenn
 * X und U die gleiche Schnittstelle haben und unter denselben Bedingungen getestet wurden
oder
 * die Schnittstelle(n) von U eine Obermenge von X ist, die sich innerhalb der Grenzen von
   X gleich verhält.
Nur wenn die zusätzlichen Möglichkeiten von U im Gesamtprojekt tatsächlich genutzt werden (wenn nicht, wäre der Austausch ja sinnlos), sind erneute Tests kaum zu vermeiden.

Und jetzt stell dir vor, dass du auf externe Module angewiesen bist, vielleicht sogar auf solche, die du nicht einmal per reverse engineerung analysieren kannst.

Nur unter Zwang oder Gewaltandrohung.

Und zu guter letzt ist es viel zu aufwendig wirklich jeden Testfall durchzuspielen. Und mit den bisher vorhandenen Testfällen mögen die bisherigen Module korrekt zu sein scheinen, aber im zusammenspiel wird dann plötzlich ein vorher nicht getester Fall relevant.

Das kann passieren, wenn man die Tests auf Stichproben reduzieren muss.

Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, ...
... dann muss ich wohl den Aufwand treiben, diese Komponenten als "Black Box" ausführlich zu testen.
Und wenn sich diese Komponenten verändern (z.B. SaaS o.ä.)? Dann müsstest du bei jeder Änderung (die du meist nicht mitkriegst) erneut manuell testen.

Selbstverständlich. Ein weiterer Grund, Fremdkomponenten zu vermeiden.

In einem privaten Projekt geht das wohl. Nicht aber auf geschäftlicher Ebene. Aus vielen Gründen.

Oh, das geht. Im Prinzip. Nur manche *wollen* sich das Leben unnötig kompliziert machen, indem sie sich auf Fremdleistungen verlassen.

So long,
 Martin