Ja, aber wenn z.B. mehrere Systeme voneinander, asynchron abhänden, dann wird es eben immer schwieriger.
Und wenn die Schnittstellen sich auch mal ändern können, weil die externe Hardware-Firma Eigenschaften nicht einhalten kann, dann gibt es u.U. mehrere gültige Versionen.
Klar kann man sagen das müsste Alles vorher exakt definiert sein, aber erklär das z.B. mal einem chinesischen Lieferanten von Hardware.
Dann ist das halt nicht automatisiert testbar und sprengt den Rahmen dieses Themas - DUnit(X) eignet sich gut für
Unit-, und Integrationstests - darüber hinaus kann man es sicherlich mit Modifikationen für andere automatisierte Tests benutzen, da es am Ende ja der Testbibliothek egal ist, was sie für Code in ihren Testmethoden ausführen.
Fakt ist, dass man eine stabile und robuste Grundlage schafft, wenn man
Unit- und Integrationstests durchführt, so dass man viel, was man früher mühsam durch "selber durchklicken" testen musste, einspart. Und ich finde, dass diese Pillepalle Beispiele bei Unittests gar nicht so weit von der Praxis entfernt sind, da man dort nunmal sehr isoliert und kleinschrittig testet. Das muss man aber am Anfang erstmal in den Kopf bekommen, da man oft schon in Gedanken den untestbaren Softwareklump, den man meist historisch gewachsen vorliegen hat, verinnerlicht hat.