Unit Testing sinnvoll?

[mjustin]

Ja, so wie Zähneputzen ("Only Floss the Teeth You Want to Keep"). GUI Tests sind ebenfalls (trotz des Aufwands) für größere Projekte oft erfolgsentscheidend. Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

In DUnit sind übrigens auch Funktionen zum GUI Test enthalten, ich habe damit noch nicht selber gearbeitet aber als 'minimalistische' Alternative zu TestComplete sind sie sicher brauchbar.

[Assarbad]

Zitat von mjustin:

Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

Dann ist der Bug formal noch immer im Programm und nicht im Test. Denn das Programm hat sicherzustellen, daß alle benötigten Ressourcen für eine Operation verfügbar sind. Zugegeben, evtl. müßte man den Test dann anpassen um auf die entsprechende Meldung zu reagieren, aber die Bringschuld liegt m.E.n. beim Programm.

[Phoenix]

Das Beispiel von hoika ist genial.
Unit-Tests sind dafür da sicherzustellen, dass alles was von den Tests abgedeckt wird und vorher ging, auch nach beliebigen Änderungen hinterher auch noch geht - oder Dich direkt darauf hinweist das etwas jetzt anders ist und Du darauf noch reagieren musst.

Wie oft macht man an Stelle A etwas und später fällt jemandem auf, dass an Stelle Q irgendwas nicht mehr funktioniert (durch Seiteneffekt der Änderung an A). Sowas decken die Unittests bei guter Abdeckung sofort auf und sparen dadurch massiv Zeit (Fehlersuche, wieder reindenken, nach der Änderung manuell alles durchtesten, wieder was vergessen, wieder später erneut suchen...).

[Meflin]

Zitat von Phoenix:

Wie oft macht man an Stelle A etwas und später fällt jemandem auf, dass an Stelle Q irgendwas nicht mehr funktioniert (durch Seiteneffekt der Änderung an A). Sowas decken die Unittests bei guter Abdeckung sofort auf und sparen dadurch massiv Zeit (Fehlersuche, wieder reindenken, nach der Änderung manuell alles durchtesten, wieder was vergessen, wieder später erneut suchen...).

Absolut. Schaut euch mal in anderen Sprach-Communities um (Ruby, Smalltalk, ...). Da ist es Gang und Gäbe zu "Units" auch die Tests mitzuliefern, was unter Anderem auch dazu führt, dass man ggf. nötige Anpassungen gefahrlos vornehmen kann.

Was agile Methoden betrifft, scheint mir die Delphi-Community allerdings etwas Yestercentury zu sein...

[mjustin]

Zitat von Assarbad:

Zitat von mjustin:

Ich erinnere mich an einen Test der fehlschlug, weil TestComplete etwas schneller als der durchschnittliche Softwareentwickler durch die Dialogmasken klickte, und Funktionen nutzte die auf unvollständig initialisierten Datenquellen arbeiteten (->Absturz).

Dann ist der Bug formal noch immer im Programm und nicht im Test. Denn das Programm hat sicherzustellen, daß alle benötigten Ressourcen für eine Operation verfügbar sind. Zugegeben, evtl. müßte man den Test dann anpassen um auf die entsprechende Meldung zu reagieren, aber die Bringschuld liegt m.E.n. beim Programm.

So meinte ich das auch, der Testlauf von TestComplete schlägt fehl, wenn die angenommene Fehlerfreiheit der Benutzeroberfläche nicht besteht. Ein "Test der fehlschlägt" ist aus Sicht der QA ein erfolgreicher Test, denn man hat einen Fehler gefunden.

[Mithrandir]

Vor dem Hintergrund des GUI-Testings finde ich ja auch deshalb WPF so genial. Hier muss ich mich nicht mit Frameworks herumschlagen, die sich durch irgendwelche GUIs klicken, sondern ich erstell einfach n Test, der den Controller testet (vorrausgesetzt natürlich, ich arbeite mit einem entsprechenden Pattern). Die Ansicht ist ja dank Binding nur lose an den Controller gebunden.

[Assarbad]

Zitat von Mithrandir:

Vor dem Hintergrund des GUI-Testings finde ich ja auch deshalb WPF so genial. Hier muss ich mich nicht mit Frameworks herumschlagen, die sich durch irgendwelche GUIs klicken, sondern ich erstell einfach n Test, der den Controller testet (vorrausgesetzt natürlich, ich arbeite mit einem entsprechenden Pattern). Die Ansicht ist ja dank Binding nur lose an den Controller gebunden.

Naja ... TestComplete nutzt auch Instrumentation und klinkt sich so in den Code ein und "sieht" bspw. die VCL-Eigenschaften. Aber das ist m.E.n. ein Problem mit Delphi/BCB: beide fördern schlechte Programmierung, indem der Programmierer dazu verführt wird den Code direkt in die Ereignisbehandlungsroutinen zu packen. Das ist natürlich am Anfang eine feine Sache, aber später nicht gerade Sahne wenn man sowas warten muß. Siehe: http://de.wikipedia.org/wiki/3-Tier#...en-Architektur

Einige Architekturen fördern diese Trennung einfach besser. Aber mit etwas Disziplin läßt sich das auch in Delphi umsetzen.

[Net7]

Zitat von Assarbad:

Zitat von Mithrandir:

Vor dem Hintergrund des GUI-Testings finde ich ja auch deshalb WPF so genial. Hier muss ich mich nicht mit Frameworks herumschlagen, die sich durch irgendwelche GUIs klicken, sondern ich erstell einfach n Test, der den Controller testet (vorrausgesetzt natürlich, ich arbeite mit einem entsprechenden Pattern). Die Ansicht ist ja dank Binding nur lose an den Controller gebunden.

Naja ... TestComplete nutzt auch Instrumentation und klinkt sich so in den Code ein und "sieht" bspw. die VCL-Eigenschaften. Aber das ist m.E.n. ein Problem mit Delphi/BCB: beide fördern schlechte Programmierung, indem der Programmierer dazu verführt wird den Code direkt in die Ereignisbehandlungsroutinen zu packen. Das ist natürlich am Anfang eine feine Sache, aber später nicht gerade Sahne wenn man sowas warten muß. Siehe: http://de.wikipedia.org/wiki/3-Tier#...en-Architektur

Einige Architekturen fördern diese Trennung einfach besser. Aber mit etwas Disziplin läßt sich das auch in Delphi umsetzen.

Hmm... heißt das, du rufst im Ereignis zb. OnBTN_Click eine Funktion zb. MaleAufCaptionEinenText auf?? Oder wägst du ab wie komplex die einzelnen Aufrufschritte sind.

[Unwissender]

Zitat von Net7:

Hmm... heißt das, du rufst im Ereignis zb. OnBTN_Click eine Funktion zb. MaleAufCaptionEinenText auf?? Oder wägst du ab wie komplex die einzelnen Aufrufschritte sind.

Hi,

ohne das für Assabard beantworten zu wollen möchte ich schon mal sagen, dass die Antwort ganz klar JA lauten wird (so hätte ich das schon gesagte interpretiert) und so gilt das für saubere Entwicklung.

Die Komplexität der Ereignisbehandlung hat nichts damit zu tun ob oder wie die Trennung in verschiedene Schichten erfolgen soll. Der Grund dass man im einfachsten Fall das GUI von der Domänenlogik trennt liegt nicht darin, dass die Komplexität sinkt oder man leichter testen kann, vielmehr haben die beiden Schichten unterschiedliche "Lebenszeiten".
So kann sich ein GUI sehr schnell und häufig ändern, ohne dass das einen Einfluss auf die Fachlichkeit hat. Auch kann es gut sein, dass Du mehrere GUIs unterstützen musst, z.B. ein Webinterface, einen Fatclient und vielleicht noch mal eine extra Oberfläche für's Smartphone.

Nimmst Du also einfach immer und sofort die Trennung vor, dann geht das in Routine über, Du arbeitest gleich richtig und musst nicht überlegen ob die Komplexität jetzt hoch genug ist es zu trennen. Alles was nicht nur mit der Darstellung in einem GUI zu tun hat, gehört da einfach nicht rein. Dass Du so leichter testen oder das GUI austauschen kannst. Auch steigt die Wartbarkeit, keiner muss lange durch die Ereignisbehandlung gehen und schauen, ob hier noch Logik drinsteckt, die nichts mit der Anzeige zu tun hat. Entsprechend weißt Du auch schon, in welcher Schicht Du Änderungen einpflegen musst, für solche an der Fachlichkeit musst Du nicht durch ein GUI durch und dort die richtige Stelle suchen. Zuguter letzt kannst Du hier auch schöner sprechende Methodennamen verwenden, da die nun die Fachlichkeit beschreiben und nicht die Behandlung eines bestimmten Buttons, der gedrückt wurde.