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.