Delphi-Anwendungen testgetrieben mit SOLID und Design-Patterns entwickeln

[generic]

Hallo DP,

ich hinterlege hier die Ressourcen und das Video von meinen Vortrag bei den Forentage 2019. Danke für das viele positive Feedback.

Hier ist das versprochene Video:
https://youtu.be/efKJPYWFoeE

Die Quelltexte zum Nachmachen sind hier im Beitrag angehängt.


SOLID:
https://en.wikipedia.org/wiki/SOLID

Entwurfsmuster / Design-Patterns:
https://de.wikipedia.org/wiki/Entwurfsmuster

Spring4D - u.a. ein dependency injection framework
https://bitbucket.org/sglienke/spring4d

DUnitX - Unittesting für Delphi der neueren Generation
https://github.com/VSoftTechnologies/DUnitX

Delphi Mocks - Mock-Framework um Testen zu vereinfachen
https://github.com/VSoftTechnologies/Delphi-Mocks

TestInsight - IDE GUI Testrunner für DUnit
https://bitbucket.org/sglienke/testinsight/wiki/Home


Werbelink - Blick ins Buch "Head First Design Patterns"
https://lesen.amazon.de/kp/embed?asi...tag=bott011-21

Werbelink - Buchkauf bei Amazon "Head First Design Patterns":
https://amzn.to/30MIl2d

[stahli]

Guter Beitrag. Vielen Dank!

Die Codestruktur mache ich ähnlich.
Tests habe ich aber noch nicht genutzt.

[Sherlock]

Prima Vortrag! Mir fallen dazu allerdings ein bis zwei Fragen/Anmerkungen ein:

• Wie stelle ich sicher, daß der Taschenrechner über den gesamten Wertebereich korrekt rechnet?
• Wie kann ich testen (lassen), daß der Taschenrechner sich korrekt verhält, wenn das Ergebnis den Wertebereich verläßt?
• Kann ich mit DUnit Schleifen formulieren, die mehrere Zahlen als Eingabe testen?
• Es wäre hilfreich, wenn beim manuellen Test des Rechners nicht die gleichen Zahlen verwendet würden, wie im Unittest. Der kritische/ungläubige/unverständige Beobachter könnte sonst glauben, daß da etwas nicht ganz koscher läuft, obwohl es natürlich nicht so ist.

Das wären ein paar Punkte, die man sicher erwähnen/einbauen könnte, auch um den typischen (für mich wenigstens) "Dazu brauche ich keinen Unittest" Einwand zu entkräften

Aber! Das ist das erste Video zu Unittests, daß mich wirklich positiv beeindruckt hat, und mir die Motivation gibt, den mir vorliegenden "Legacy Code" mit Unittests zu unterfüttern, bzw. überhaupt erst testbar zu machen.

:thumb:

Sherlock

[generic]

Danke für das Lob.

Die Punkte welche du ansprichst, können natürlich mit mehr Tests angegangen werden.
Du hast auch gerade direkt paar best-practices angesprochen.
Es macht natürlich immer Sinn, auf extreme zu prüfen - also Maximal- und Minimal-Werte.
Wenn es um Listen geht, welche übergeben werden, keine Werte und mindesten zwei Werte übergeben.
Schließlich muss man an jeden Ausführungszweig vorbei kommen und Großen abklopfen, mit den Testwerten.

Die Unit-Tests-Frameworks bzw. deren Tests können auch Listen entgegennehmen. Dann wird der gleiche Test, mit einer Liste von Werten mehrfach ausgeführt. Das sieht dann so aus, als ob mehrere Tests programmiert worden sind.

Bei DUnitX wird per Attribute eine Anzahl von Werten übergeben oder via Provider-Methode.
Siehe:
https://github.com/VSoftTechnologies...derExample.pas
oder Zeile 55 in:
https://github.com/VSoftTechnologies...es.General.pas

Ich werde noch Follow-up Videos erstellen u.a. über:
* DUnitX, weil es einfach moderner ist
* Delphi-Mocks

Ich kann mir auch vorstellen über Buildskripte, continuous integration (CI) und continuous deployment (CD) zu Vloggen.

Thema "ich brauche keine Unittests":
Es ist bei allen mit denen ich spreche die gleich Diskussion.
Unittest machen Aufwand, der kostet Geld.
Man muss für neue Programmteile die Test programmieren. Man muss sie pflegen, wenn sich alte Programmteile ändern.

Für diese Investition erhält man Gegenwerte!

Für mich als Backend-Entwickler fällt als erstes ab, dass ich nicht auf die GUI Leute warten muss, bis die den Knopf fertig haben, der mein Programmteil aufruft.

Ich kann direkt die Unit schreiben und über die Tests ausführen und ggf. debuggen.
Dadurch dass die Schnittstelle zur GUI definiert wurde und für die Tests Musterwerte bestimmt sind,
können die Tests für mich einfacher geschrieben werden. Zusätzlich können die GUI Leute weiter arbeiten obwohl ich noch nicht fertig bin, indem die einfach einen Mock von meiner Klasse bauen, welcher statisch die gleichen Werte aus den Tests liefert. In den meisten Fällen werden dann sogar die Mocks aus den Tests verwenden (während der Entwicklung).

Daher kann hier Geld gespart werden, weil niemand auf den anderen warten muss.

Die andere Sache ist, wenn ich als Entwickler ein bestehendes Projekt übernehme.

Wenn ich die Unittests ausführen kann, dann weiß ich, dass das Programm funktioniert.
Sollte ich das Programm durch Unwissenheit so verändern, dass eine Stelle kaputt geht, dann bekomme ich das mit, durch die Tests. Des Weiteren dokumentieren die Tests Funktionen. Ich kann mir ein Test anschauen und sollte dann verstehen, wie die Unit, Methode funktioniert.

D.h. ich spare wieder, weil ich mich besser Informieren kann und ich sichere mich ab, dass ich nichts kaputt spielen kann, weil ich die Anwendung mit den 200k Zeilen Quelltext nicht vollständig verstehe.

Wenn jetzt noch mit Bugs-First und Test-First gearbeitet wird, dann verbessert dieses die Dokumentation durch die Tests und die Testabdeckung wird höher. Zusätzlich fällt eine bessere Qualität für die Anwendung raus. Diese spart wieder, weil die Anwendung wartbarer wird.

Unter dem Strich, glaube ich, dass man dadurch +-0 aus der Sache rauskommt (Zeitaufwand für die Entwicklung über einen langen Zeitraum), aber das Programm erheblich besser ist.

Das schützt natürlich wieder die Unternehmens-Investition, weil das Programm länger auf dem Markt sein kann und nicht die nächste Version wieder vollständig neu programmiert werden muss.