Unit Testing sinnvoll?

[stahli]

Hallo alle,

ich habe mir mal Videos zum Unit Testing angesehen und der Sinn erschließt sich mir noch nicht wirklich.

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

GUI-Testing wie TestComplete ist natürlich schon beeindruckend, allerdings im Handling selbst sehr komplex und nicht gerade billig ;-)

Wirklich hilfreich scheint mir aber nur letzteres...
Was meint Ihr?

[Assarbad]

Erstmal: ja. Unit Testing stellt sicher, daß kleine Code-Einheiten (eben die "Units", aber nicht im Delphi-Sinn) entsprechend ihrer Spezifikation funktionieren. Um es ein Stück weiter zu treiben: Unit Tests können als Spezifikation herhalten.

Zitat:

Zitat von stahli (Beitrag 1057987)

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

Du vergißt, daß für das komplette Programm auch Integrationstests (funktionieren die verschiedenen "Einheiten" und "Module" zusammen?) und Systemtests (wie funktioniert das ganze dann quasi aus Benutzersicht?) fehlen.

[Meflin]

Ist anschnallen sinnvoll?

Mehr muss man dazu imo nicht sagen :P

[mleyen]

Anschnallen ist ein ungünstig gewähltes Vergleichswort.
Eher sowas wie:
"Ein gebautes System welches erkennt was du beim Losfahren, deiner Meinung nach zu urteilen, alles falsch gemacht haben könntest"

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1057987)

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...
Sehe ich das falsch?

Das ist ja auch dann kein Unit-Test mehr sondern Modul-/Integrations-/Systemtests.

[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.

[hoika]

Hallo,

Zitat:

Die problematischen Fehler sind doch m.E. komplexerer Natur, als dass sie sich mit solchen simplen Funktionsaufrufen testen ließen...

Nein und ja ...

Bsp.

Delphi-Quellcode:

function Add2(Value: Integer);
begin
  Result:= Value+2;
end;

Jetzt kommt einer und ändert was

Delphi-Quellcode:

function Add(Value: Integer; AddValue: Integer);
begin 
  Result:= Value+AddValue;
end;

function Add2(Value: Integer);
begin
  Result:= Add(Value,2);
end;

Soweit so gut.

Wie stelle ich aber sicher, dass das Add2 immer noch das tut was es soll ?
Es könnte ja jemand die Add verändern.

Das stellen Unit-Tests sicher.


Und was die Komplexität betrifft.
Ein komplexes Problem wird in kleinere Einheiten unterteilt, die einzeln getestet werden.
Natürlich muss auch das Gesamt-Problem getestet werden.

Das schöne am Unit-Test ist, dass du gezwungen wirst, testbaren Code zu schreiben.
Eine Button1Click-Funktion in einem Form darf ebend keinen Code enthalten,
sondern nur (externe) Funktion aufrufen, die völlig separat ist
und damit auch ohne das Form getestet werden kann.


Heiko

Heiko

[Assarbad]

Zitat:

Zitat von mjustin (Beitrag 1058044)

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...).

[mjustin]

Zitat:

Zitat von Assarbad (Beitrag 1058073)

Zitat:

Zitat von mjustin (Beitrag 1058044)

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:

Zitat von Mithrandir (Beitrag 1058126)

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.

[Meflin]

Zitat:

Zitat von Phoenix (Beitrag 1058088)

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...

[Net7]

Zitat:

Zitat von Assarbad (Beitrag 1058148)

Zitat:

Zitat von Mithrandir (Beitrag 1058126)

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:

Zitat von Net7 (Beitrag 1075100)

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.

[Assarbad]

Was soll man dem noch hinzufügen :zwinker:

In der Tat würde die Trennung immer erfolgen, da statt einer grafischen Benutzeroberfläche ja auch eine Textmodusoberfläche stehen könnte ...

[s.h.a.r.k]

Wie viel Zeit wird von euch denn für solche Unit-Tests denn investiert? Ich persönlich habe den Sinn zwar schon verstanden, sehe es aber teilweise als unwirtschaftlich an, wenn ich mir da so manche Videos angeschaut habe. Klar, wenn ein blöder Fehler versteckt ist, kann es sein, dass ich (also der Programmierer) dann teurer kommt, da er erst mal den Fehler ausfindig machen muss. Aber eine Kennzahl wäre hier schon mal interessant zu wissen. Gerne auch prozentual zu den Stunden, die wirklich am Projekt selbst gearbeitet wird.

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1075182)

Wie viel Zeit wird von euch denn für solche Unit-Tests denn investiert? Ich persönlich habe den Sinn zwar schon verstanden, sehe es aber teilweise als unwirtschaftlich an, wenn ich mir da so manche Videos angeschaut habe.

Soviel wie es eben benötigt.

Unit-Tests können teilweise ja sogar als Ersatz einer Spezifikation dienen. Die Idee ist ja bei einer möglichst großen Abdeckung mit Tests die darunterliegende Implementation beliebig abändern zu können und sicher zu sein, daß es noch funktioniert.

Abgesehen davon ist natürlich "unwirtschaftlich" etwas weithergeholt. Wenn man bedenkt daß die meisten Projekte mit schlechter Testabdeckung und/oder Planung schwer wartbar sind und die Wartung (und Fehlersuche/-behebung) sehr lange dauert, relativiert sich das wieder.

Sobald du mal, statt eine Funktion 100x über irgendwas laufen zu lassen und trotzdem nicht zu wissen ob deine Änderung korrekt war, eine kleine Änderung gemacht hast und dann deine Tests drüberlaufen lassen kannst und mit Gewissheit weißt, daß die Änderungen bei erfolgreichem Testdurchlauf korrekt sind, dürfte dir die Wirtschaftlichkeit klar werden ;)

[s.h.a.r.k]

Muss mir dann wahrlich mal anschauen, wie ich denn diese Tests dann erstelle. Mir erscheint es nur bei kleineren Projekten weniger sinnvoll, vor allem weil ich immer alleine dran gearbeitet hatte. Aber wenn mehrere Personen an etwas frickeln, wird es dann wahrlich schon interessanter. Danke für die nochmalige Erläuterung :thumb:

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1075567)

Mir erscheint es nur bei kleineren Projekten weniger sinnvoll, vor allem weil ich immer alleine dran gearbeitet hatte.

Aaaah, verstehe. Darauf willste hinaus. Das ist natürlich korrekt. Bei kleinen Tools nimmt man gern Abkürzungen. Ich habe mich allerdings schon mehrfach dabei erwischt, daß Abkürzungen dazu führten, daß ich mich nach einem halben Jahr oder länger fragte, was mein Ich in der Vergangenheit sich wohl bei dieser oder jener Sache dachte. Da ist es dann gut Kommentare oder Tests für die entsprechende Funktion/Zeile zu haben. Die Tests sind in dem Sinne ja auch durchaus Dokumentation.

Aber die Integration der Tests kann in der Tat problematisch sein ... je nachdem was man schreibt und in welchem Stil. In diversen Sprachen haben sich da Standards herausgebildet. Was es bei Delphi ist, weiß ich nicht ... würde mich allerdings durchaus interessieren :)

[stahli]

Ich bin da etwas hin- und hergerissen.

Über solche Tests kann man doch auch nur einige Dinge und Situationen prüfen, die man in einem starren Ablauf nachvollziehen kann.
Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Ein weiteres Problem ist in der GUI-Anbindung zu sehen. Gibt es hier irgendwelche (zeitkritischen) Probleme, kann man das mit Unittesting auch nicht feststellen.
Da scheint mir ein GUI-Testing schon sinnvoller, aber so richtig überzeugt mich das auch nicht (vom Aufwand/Nutzen her).

Also ich bin noch nicht sicher, was ich davon halten soll (ob sich der Aufwand lohnt).

[Assarbad]

Zitat:

Zitat von stahli (Beitrag 1075615)

Über solche Tests kann man doch auch nur einige Dinge und Situationen prüfen, die man in einem starren Ablauf nachvollziehen kann.
Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Aaah. In der Tat. Hierbei kommen dann "Integration Tests" und "System Tests" zum Einsatz.

Stell dir den jeweiligen Unit Test einfach als Möglichkeit vor die dokumentierte oder implizierte Funktionsweise der Funktion zu testen, jedoch nicht deren Einbindung in das Produkt. Dafür gibt es, wie gesagt, wiederum andere Varianten.

Zitat:

Zitat von stahli (Beitrag 1075615)

Ein weiteres Problem ist in der GUI-Anbindung zu sehen. Gibt es hier irgendwelche (zeitkritischen) Probleme, kann man das mit Unittesting auch nicht feststellen.

Absolut korrekt. Aber hier kann bspw. die Trennung deiner Anwendung in verschiedene Ebenen (siehe http://de.wikipedia.org/wiki/3-Tier#...en-Architektur) helfen. Vorteil: du kannst deine Tests bspw. in einer Kommandozeilenversion automatisieren. Damit haste sicher in den meisten Fällen mehr als 90% der Funktionalität einer Anwendung abgedeckt, es sei denn du mischst Logik und Präsentation (was Delphi leider ein wenig fördert, s.o.).

Zitat:

Zitat von stahli (Beitrag 1075615)

Also ich bin noch nicht sicher, was ich davon halten soll (ob sich der Aufwand lohnt).

Okay, mach es doch einfach mal anhand eines kleinen Projekts. Und dann notierst du exakt den Zeitaufwand. Ich denke aufgrund der Erfahrung mit Projekten ohne Tests kannste es sehr bald abschätzen. Aber Gold wert sind Unit Tests sobald du eine tiefgreifende Änderung am System vornehmen willst.

[BUG]

Zitat:

Zitat von stahli (Beitrag 1075615)

Wenn ich eine Funktion Addiere(A,B) mit 1 und 2 prüfe, kommt korrekt 3 heraus.
Auf 100 und 200 teste ich nicht, aber durch einen Fehler in der Funktion kommt 400 heraus. Den Fehler erkennt man also auch über ein Unit-Testing nicht.

Man kann natürlich nicht alles abdecken.
Aber überlege, was du testest, wenn du "live" beim Programmieren testest.

z.B.

A,B: Integer

Dann hast du zum Beispiel Eigenschaften wie:
1) A < 0, A > 0, A = 0
2) B < 0, B > 0, B = 0
3) A < B, A > B, A = B

Wenn du für alle diese Kombinationen von Eigenschaften ein Beispiel testest, solltest du beim Addieren relativ gut hinkommen.
(Ob das wohl in der Praxis irgendjemand so ausführlich macht :mrgreen:)

Zusätzlich kannst du dir Eingabewerte merken, bei denen es in der Vergangenheit Probleme gab:
Wenn mal bei ADD(6,-4) = 42 herauskam und du den Fehler gefixt hast, dann kannst du sichergehen, das der Fehler nicht nochmal auftritt (z.B. wenn du wegen eines anderen Problems eine frühere Version aus dem SVN holst).

Und dann gibt es noch die Möglichkeit, Fehler zu testen, die einfach häufig sind:
Grenzfälle, Off-By-One-Errors, usw.


Zudem kannst du beim Unit-Test ja relativ gut abschätzen, wo der Fehler herkommt, was beim GUI-Testen schwerer ist.

[Viktorii]

Zitat:

Zitat von Unwissender (Beitrag 1075109)

Zitat:

Zitat von Net7 (Beitrag 1075100)

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.

Ich finde das klingt alles sehr einleuchtend und zu dieser Vorgehensweise möchte ich auch hin.

Allerdings hapert es bei mir etwas an der praktischen Umsetzung.

Gibt es mal irgendwo ein (kleines) open source Programm, welches nach diesem Prinzip aufgebaut ist, nicht zu komplex ist damit man nicht direkt erschlagen wird, aber auch nicht zu simpel ist damit man die praktische Anwendung auch erkennt?? Jo, drei Wünsche auf einmal :stupid:

Bei allem was ich hiermal so runtergeladen habe (soweit ich mich erinnere) war diese Prinzip nicht wirklich da.

Würde mich über den einen oder anderen Tipp sehr freuen :-D

[mquadrat]

Wir stellen gerade auf Test-Driven-Developement um. Also ja, ich denke schon, dass Unit-Tests Sinn machen ;)

Kleinere Projekte eignen sich hervorragend zum üben, bevor man sich an die alten großen Bestandsprojekte macht.

[Viktorii]

Bezüglich #24: Also gibt es sowas in Delphi nicht (viel)?

Stimmt die These von mquadrat also doch irgendwo??

http://www.delphipraxis.net/157452-d...re-design.html

[Assarbad]

Zitat:

Zitat von Viktorii (Beitrag 1078576)

Stimmt die These von mquadrat also doch irgendwo??

http://www.delphipraxis.net/157452-d...re-design.html

Ich würde ihm zustimmen. Es läuft im Grunde auf das gleiche Argument hinaus wie meines, daß Delphi zu schludriger Programmierung verleitet ... (und die oft kopierten Codebeispiele ebenso).

[Viktorii]

Schade :(

Na, dann werde ich mich ab jetzt mal mehr in den besagten C# Foren rumtreiben...

[stahli]

Ich habe das programmieren vor 30 Jahren autodidaktisch gelernt.
Dann ist irgendwo logisch, dass man (mit Delphi) irgendwelche Berechnungen in einer Ereignisbehandlung durchführt. Man befasst sich ja auch nicht bei den ersten Schritten mit dem Erstellen von Klassen.

Inzwischen sehe ich die Sinnhaftigkeit der Trennung in mehrere Schichten durchaus ein. Zumindest für ernsthaftere und komplexere Projekte.

Wenn ich aber mal schnell einen kleinen Test zusammenklicke, werde ich mich nicht zwangsläufig mit Klassendeklarationen herumschlagen.

Also die Möglichkeit, mit Delphi auch schnell und schludrig zu arbeiten, sollte Dich nicht vertreiben. Du kannst ja jederzeit Dein Projekt auch "sauber" aufbauen.
Man muss halt Aufwand und Nutzen abwägen - auch im Hinblick auf Wartbarkeit und möglicher späterer Migration.