Dankesehr für die Infos und Videos
UnitTests finde ich sind generell recht notwendig heutzutage, um fehlerfrei zu programmieren.
Testen von separaten BusinessLogik-Units ist aber die eine Sache, das sollte klar sein.
Ich frage mich nur ob es auch spezielle, gute Best-Practices Tipps und Prozesse für die Tests von verteilten System gibt, wo Alles zusammen kommt
(z.B. mit separaten Business-Units, mehreren asynchronen, externen Geräten, Embedded-Systemen, mehreren asynchronen Schnittstellen, Server, Cloud-Diensten, mobilen Apps, Logger-Services, etc.).
In solchen Fällen halte ich es so das ich auf z.B. mobilen Geräten kleine "Selbst-Test" und "Debug" Funktionen einbaue, als Ergänzung zu den UnitTests.
Mit denen ich das Verhalten etwas besser im realen Betrieb simulieren und "testen" kann.
Bei den
Unit-Tests komme ich da irgendwie an Grenzen, um komplexere Systeme zu Testen.
In der Regel funktioniert die Business-Logik bei komplexen Systemen mit zig. Partnern nicht ohne die ganzen externen Partner lauffähig zu haben.
Wenn aber mehrere Partner gleichzeitig entwickelt werden, und in verschiedenen Versionen verfügbar sind, dann wird es mühsam.
Bei solchen Systemen kann man natürlich alles separat Testen, mit viel Glück, aber oft gibt es weder Client noch Server, oder etwas Unvorhergesehenes kommt dazwischen und braucht Änderungen.
Solche
Unit-Tests könnten z.B. je nach Versionsstand mehrere Versionen des Gesamtsystems abdecken, so dass ältere und neuere Units noch nebeneinander existieren können.
Es ist wohl ein typisches Henne-Ei Problem.
Ich habe auch schonmal ein komplettes Embedded-System simuliert, bevor es zu 100% existierte, um die App dafür schneller zu entwickeln.
Der Aufwand war aber nur zu rechtfertigen weil ich die Simulation dem Kunden auch als Gimmick für Schulungszwecke angeboten habe.
Gerade bei Mobil-Entwicklung kommen die ganzen Geräte-Spezifischen Funktionen noch dazu (Permissions, Orientation, Sensoren, ...), die man nur schlecht auf Desktops simulieren kann.
Zumindest teste ich das meistens auf den mobilen Geräten selbst.
Wenn man zuviel unter
Win32 simuliert kann es passieren das die App dann plötzlich sofort abstürzt, und man kann nicht mehr sagen warum eigentlich.
Deshalb lege ich mir solche Geräte-"Features" in separate kleine Units, die ich wunderbar separat Testen kann, und die dann später in einer komplexeren App einfach zusammengesteckt werden und nutzbar sind (diese können sich aber leider trotzdem immer wieder mit anderen "Features" beissen, oder die
OS-Updates werfen die Funktion raus).
Die kleinen Hello-World Beispiele für
Unit-Tests sind sicher gut um sich einzuarbeiten, aber was meistens fehlt sind auch realere Beispiele, aus dem echten Leben.
Ich hoffe das es mit der Video-Serie noch weitergeht, auch mehr in diese Richtung.
Vielleihct hängt die mangelnde Akzeptanz von
Unit-Tests auch damit zusammen das man den Zusammenhang und die Lösung von "Hello World" zu echten Problemen nur schwer erkennen kann.
Falls jemand gute Hinweise hat wie man solche komplexeren Strukturen noch besser Entwickeln und Testen sollte, immer her damit.