Spring-DI / DelegatedConstructor / Factory für Dummies

[s.h.a.r.k]

Zitat von stahli:

Mal reagiert die VCL etwas anders als erwartet (was z.B. irgendwelche Nachrichtenbehandlungen betrifft) oder in meinem Framework werden irgendwann Objekte nicht wie erwartet behandelt. Jedenfalls treten die Fehler meist nur durch eine intensive Userbedienung auf. In den Fällen dürfte ein Unittesting nicht helfen.

Klingt irgendwie komisch... Egal, wie die Nachrichtenbehandlung abläuft, es müsste immer das selbe Ergebnis folgen, egal, wie intensiv die Userbedienung ist. Selbst, wenn du Threads mit einbaust, muss dein Konzept immer die gleichen Ergebnisse liefern, ebenso muss dein Framework immer gleich mit Objekten umgehen, eben auf abstrakte Art und Weise. Die Besonderheiten sollten imho von den Objekten selbst gehandhabt werden.

[stahli]

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

[Stevie]

Zitat von stahli:

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

Du arbeitest allein an deinem Sourcecode. Stell dir vor, es gibt ein Team von Entwicklern und es gibt bestimmte Spezifikationen für die unterschiedlichen Module und Klassen. Baut sich nun jeder Entwickler seine Button1 Projekte, um zu testen, ob die Klassen und Methoden das machen, was sie sollen? Ob nun TDD betrieben wird, oder erst drauflos gecodet wird und hinterher der Unittest geschrieben wird, ist dafür erstmal unerheblich. Was, wenn nun Funktionialität hinzukommt, sich Spezifikationen ändern, jemand Dinge refactored oder ein unbedarfter Azubi auf den Code losgelassen wird? Willst du deine komplette zig Millionen LoC schwere Anwendung durchtesten, um herauszufinden, ob alles noch funktioniert?

[stahli]

Ok, in Bezug auf die Teamarbeit ist das gewissermaßen schon nachvollziehbar. Damit habe ich aber (leider oder zum Glück?) keine Erfahrungen.
Die Testfälle zu organisieren ist aber sicher auch nicht trivial und kostet viel Zeit und Arbeit.

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mich mit für mich neuen Grundlagen zu befassen. Im nächsten Leben werde ich mal bei Dir Azubi und lerne das gleich richtig.

[Uwe Raabe]

Zitat von stahli:

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mit frü mich neuen Grundlagen zu befassen.

Dann geht es dir wie dem Bauern, der keine Zeit hat, einen Zaun zu bauen, weil er die Kühe einfangen muss...

[stahli]

Zitat von Uwe Raabe:

Dann geht es dir wie dem Bauern, der keine Zeit hat, einen Zaun zu bauen, weil er die Kühe einfangen muss...

[OT]Ach das geht schon erst mal. Um die Weide ist ein kleiner Graben und wenn die Melkanlage erst mal auf vollen Touren läuft, dann schaue ich mir an, wie man am besten stabile Zäune baut [/OT]

[s.h.a.r.k]

Du weißt aber nicht, was du eigentlich verpasst, wenn du dich endlich mal um den Zaun kümmern würdest