Von 0 auf 100 - DUnitX - Ein Testframework für Delphi

[generic]

Hallo DP,

da nächste Tutorial Video ist online. In der Reihe "Von 0 auf 100" möchte ich kurze Videos veröffentlichen, mit welchen Ihr schnell in einen neue Technologie starten könnt.

DUnitX ist wie DUnit ein Testframework womit ihr einfach Unit-Testen könnt. Was das ist und worum es geht, wird in dem Video nicht erklärt. Ihr könnt das aber gerne Nachlesen oder einfach mein Refactoring Video schauen - Ebenfalls hier in der DP unter Tutorials zu finden.

Im diesen Video stelle ich das Testframework DUnitX vor und erzähle von den Unterschieden für DUnit. Es werden die Installation und die Benutzung erklärt. Des Weiteren stelle in den Testrunner TestInsight vor.

Hier das Video:
https://www.youtube.com/watch?v=2WPlVAz-cTU


Links aus dem Video:
DUnitX - Unittesting für Delphi der neuesten Generation
https://github.com/VSoftTechnologies/DUnitX

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

[dummzeuch]

Danke, nettes Tutorial, auch wenn die Puristen natürlich sofort wieder meckern werden, dass man Tests schreibt, bevor man den zu testenden Code schreibt.

Jetzt weiss ich endlich, wozu Attribute gut sein können, bisher fehlten mir dafür nämlich sinnvolle Beispiele.

[stahli]

Danke für das Tutorial!

[generic]

Zitat:

Zitat von dummzeuch (Beitrag 1449933)

Danke, nettes Tutorial, auch wenn die Puristen natürlich sofort wieder meckern werden, dass man Tests schreibt, bevor man den zu testenden Code schreibt.

Jetzt weiss ich endlich, wozu Attribute gut sein können, bisher fehlten mir dafür nämlich sinnvolle Beispiele.

Danke für das Lob. Recht hast du! Ich hab das in dem Video weg gelassen, weil ich mich bei "0 auf 100" nur auf die Technologie konzentrieren will.
In dem letzten langen Video (Delphi-Anwendungen testgetrieben mit SOLID und Design-Patterns entwickeln) behandelt und dort predige ich auch gegen Ende des Videos - "TEST FIRST"!

[MicMic]

Ich habe mir mal das Video angeschaut.
Ich verstehe ehrlich gesagt nicht, wieso/weshalb/warum? :) Was ist der Sinn und Zweck von DUnitX?
Gruß Mic

[stahli]

Hast Du sein erstes Video zu DUnit (einfachere Variante) schon gesehen?
https://youtu.be/efKJPYWFoeE

Dort wird der Grund etwas genauer erklärt.

Es geht bei Tests generell darum, den Code später nicht in einer Funktion zu ändern, so dass Ergebnis bei AufrufB passt aber gleichzeitig das
bisher korrekte Ergebnis für AufrufB zerstört wird. Es soll also Nebeneffkte bei Codeänderungen verhindern.

Man kann das so weit treiben, dass man immer erst Tests schreibt und dann erst die Funktionen anpasst.

Das muss halt jeder selbst entscheiden, wie weit das sinnvoll ist oder nicht.

[jaenicke]

Wir testen bestimmte Basisunits und Basisfunktionen. Zum Beispiel sind das Funktionen für die Zerlegung und Analyse von Strings usw., die sehr oft an vielen Stellen verwendet werden und so bei Fehlern heftige (aber nicht schnell findbare) Probleme auslösen könnten.

[HeZa]

Danke für das Video.

Das mit dem Testfirst ist übrigens immer ein Problem, wenn man mit dem Testen anfängt. Da ist dann meist schon eine Menge Code vorhanden.

In solchen Fällen hilft es (wie Bernd auch kurz gezeigt hat) des Teufels Advokaten zu spielen und durch bewusstes Einbauen von Fehler zu prüfen, ob diese auch gefunden werden. Dabei überprüft man auch gleich seine Testabdeckung. Eine sehr gute Beschreibung dieses Vorgehen findet man im Blog von Mark Seamann.

https://blog.ploeh.dk/2019/10/07/devils-advocate/
https://blog.ploeh.dk/2019/10/14/tau...cal-assertion/

Diesen Blog Beitrag von Ihm finde ich auch lesenswert, ist aber ein ganz anderes Thema. :-)
https://blog.ploeh.dk/2019/09/30/10x-developers/

Ciao Heinz

[Stevie]

:thumb: für TestInsight Werbung ;)

Kleiner Hinweis: man muss nicht selbst das TESTINSIGHT define hinzufügen, dafür gibs im Projekt Kontextmenü den Eintrag "TestInsight Projekt" den einfach anklicken, dann wird das gemacht und man sieht ein Häkchen davor (sieht man bei 6:21 auch kurz, dass es angehakt ist, nachdem es manuell hinzugefügt wurde)

P.S. Für schicke Attribute braucht man kein DUnitX nutzen, das kann man dem DUnit auch beibringen

[generic]

Screenshot von dem besagten Kontextmenü (bei 6:21 aus dem Video).

Anhang 51731

Uii, hab ich auch was dazu gelernt. Habe den Knopf noch nie gesehen.

[TigerLilly]

Danke für das Video - das fasst die Verwendung sehr gut zusammen.

Eine Anregung habe ich: Ich fände es gut, wenn die Autoren der Bibliotheken genannt (und gewürdigt) würden.

[Der schöne Günther]

Ich habe mich schon immer gefragt weshalb ich DUnitX und nicht DUnit verwenden sollte. Ich bin super gespannt, das ziehe ich mir heute rein. Vielen Dank! 🎉

[generic]

Zitat:

Zitat von Der schöne Günther (Beitrag 1450027)

Ich habe mich schon immer gefragt weshalb ich DUnitX und nicht DUnit verwenden sollte. Ich bin super gespannt, das ziehe ich mir heute rein. Vielen Dank! 🎉

Die Antwort gebe ich nicht wirklich. Funktionieren beide gut!
Beide können das NUnit.XML erzeugen (habe ich gestern gelernt - dachte DUnit kann es nicht - aber Stevie hat mich aufgeklärt).

Die Überlegung ist doch nur ob du dir was installieren willst oder es schon mit in Delphi drin ist.

Vor RIO ist DUnit drin.
Seit RIO die DUnitX.

TestInsight bekommt man bestimmt auch mit DUnit flink zum laufen.

[Stevie]

DUnit ist auch in Rio noch drin und DUnitX ist auch schon seit ein paar Versionen vor Rio drin.

Just heute hab ich mal spaßeshalber einige mit DUnitX erstellte Tests auf DUnit umgestellt - war ne Sache von paar Minuten und die Tests selber laufen in DUnit um einige ms schneller - das mag marginal erscheinen, aber bei TDD und Ausführung von zig Tests im Hintergrund bzw während dem Entwickeln will man möglichst wenig Overhead durch das Testframework an sich haben.

Mit ein bissle Trickserei bekommt man auch das DUnitX Assert mit DUnit verknotet, wenn man das lieber benutzen mag, als die CheckXXX Methoden von DUnit.

[exilant]

Zitat:

Zitat von Der schöne Günther (Beitrag 1450027)

Ich habe mich schon immer gefragt weshalb ich DUnitX und nicht DUnit verwenden sollte. Ich bin super gespannt, das ziehe ich mir heute rein. Vielen Dank! 🎉

Und habe mich schon immer gefragt weshalb ich überhaupt DUnitX oder DUnit verwenden sollte. Ich bin auch gespannt und schaue mir das an.

[Stevie]

Zitat:

Zitat von exilant (Beitrag 1450110)

Und habe mich schon immer gefragt weshalb ich überhaupt DUnitX oder DUnit verwenden sollte. Ich bin auch gespannt und schaue mir das an.

Schreibe niemals Unit Tests!

[Rollo62]

Dankesehr für die Infos und Videos :thumb:

UnitTests finde ich sind generell recht notwendig heutzutage, um fehlerfrei zu programmieren.
Testen von separaten BusinessLogik-Units ist aber die eine Sache, das sollte klar sein.

Ich frage mich nur ob es auch spezielle, gute Best-Practices Tipps und Prozesse für die Tests von verteilten System gibt, wo Alles zusammen kommt
(z.B. mit separaten Business-Units, mehreren asynchronen, externen Geräten, Embedded-Systemen, mehreren asynchronen Schnittstellen, Server, Cloud-Diensten, mobilen Apps, Logger-Services, etc.).

In solchen Fällen halte ich es so das ich auf z.B. mobilen Geräten kleine "Selbst-Test" und "Debug" Funktionen einbaue, als Ergänzung zu den UnitTests.
Mit denen ich das Verhalten etwas besser im realen Betrieb simulieren und "testen" kann.

Bei den Unit-Tests komme ich da irgendwie an Grenzen, um komplexere Systeme zu Testen.
In der Regel funktioniert die Business-Logik bei komplexen Systemen mit zig. Partnern nicht ohne die ganzen externen Partner lauffähig zu haben.
Wenn aber mehrere Partner gleichzeitig entwickelt werden, und in verschiedenen Versionen verfügbar sind, dann wird es mühsam.

Bei solchen Systemen kann man natürlich alles separat Testen, mit viel Glück, aber oft gibt es weder Client noch Server, oder etwas Unvorhergesehenes kommt dazwischen und braucht Änderungen.
Solche Unit-Tests könnten z.B. je nach Versionsstand mehrere Versionen des Gesamtsystems abdecken, so dass ältere und neuere Units noch nebeneinander existieren können.
Es ist wohl ein typisches Henne-Ei Problem.
Ich habe auch schonmal ein komplettes Embedded-System simuliert, bevor es zu 100% existierte, um die App dafür schneller zu entwickeln.
Der Aufwand war aber nur zu rechtfertigen weil ich die Simulation dem Kunden auch als Gimmick für Schulungszwecke angeboten habe.

Gerade bei Mobil-Entwicklung kommen die ganzen Geräte-Spezifischen Funktionen noch dazu (Permissions, Orientation, Sensoren, ...), die man nur schlecht auf Desktops simulieren kann.
Zumindest teste ich das meistens auf den mobilen Geräten selbst.
Wenn man zuviel unter Win32 simuliert kann es passieren das die App dann plötzlich sofort abstürzt, und man kann nicht mehr sagen warum eigentlich.
Deshalb lege ich mir solche Geräte-"Features" in separate kleine Units, die ich wunderbar separat Testen kann, und die dann später in einer komplexeren App einfach zusammengesteckt werden und nutzbar sind (diese können sich aber leider trotzdem immer wieder mit anderen "Features" beissen, oder die OS-Updates werfen die Funktion raus).

Die kleinen Hello-World Beispiele für Unit-Tests sind sicher gut um sich einzuarbeiten, aber was meistens fehlt sind auch realere Beispiele, aus dem echten Leben.
Ich hoffe das es mit der Video-Serie noch weitergeht, auch mehr in diese Richtung.
Vielleihct hängt die mangelnde Akzeptanz von Unit-Tests auch damit zusammen das man den Zusammenhang und die Lösung von "Hello World" zu echten Problemen nur schwer erkennen kann.

Falls jemand gute Hinweise hat wie man solche komplexeren Strukturen noch besser Entwickeln und Testen sollte, immer her damit.

[Klaus01]

.. ist es nicht so, das Unit-Tests die Programmlogik, die Eigenschaften testet.
Ich kann damit auch testen wie sich das Programm gegenüber Schnittstellen verhält.
Die Schnittstelle (des anderen Systems, wenn nicht vorhanden) muss ich anhand der Spezifikation nachbilden.

Das Zusammenspiel von mehreren Systemen ist dann das Thema des/der Integrationstests.
Das kann kein Unit-Test leisten.

Grüße
Klaus

[Stevie]

Es gibt sicherlich die Notwendigkeit, automatisierte Integrations- oder Systemtests zu haben, allerdings kann man vieles davon schon in kleiner dimensionierten Tests abhandeln.
Das geht aber nur, wenn die Architektur selbst nicht komplett chaotisch ist (komplex != kompliziert). So braucht man z.b. nicht die komplette Infrastruktur wenn man eine bestimmte Komponente aus dem Verbund testen will, sondern muss nur dessen Kommunikationspartner simulieren/mocken.

Was man auf kleiner Ebene bei Klassen/Funktionen einhält (SRP, SLA, etc), sollte man auch auf höherer Ebene tun.

[Rollo62]

Ja, aber wenn z.B. mehrere Systeme voneinander, asynchron abhänden, dann wird es eben immer schwieriger.
Und wenn die Schnittstellen sich auch mal ändern können, weil die externe Hardware-Firma Eigenschaften nicht einhalten kann, dann gibt es u.U. mehrere gültige Versionen.

Klar kann man sagen das müsste Alles vorher exakt definiert sein, aber erklär das z.B. mal einem chinesischen Lieferanten von Hardware.

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1450170)

Ja, aber wenn z.B. mehrere Systeme voneinander, asynchron abhänden, dann wird es eben immer schwieriger.
Und wenn die Schnittstellen sich auch mal ändern können, weil die externe Hardware-Firma Eigenschaften nicht einhalten kann, dann gibt es u.U. mehrere gültige Versionen.

Klar kann man sagen das müsste Alles vorher exakt definiert sein, aber erklär das z.B. mal einem chinesischen Lieferanten von Hardware.

Dann ist das halt nicht automatisiert testbar und sprengt den Rahmen dieses Themas - DUnit(X) eignet sich gut für Unit-, und Integrationstests - darüber hinaus kann man es sicherlich mit Modifikationen für andere automatisierte Tests benutzen, da es am Ende ja der Testbibliothek egal ist, was sie für Code in ihren Testmethoden ausführen.

Fakt ist, dass man eine stabile und robuste Grundlage schafft, wenn man Unit- und Integrationstests durchführt, so dass man viel, was man früher mühsam durch "selber durchklicken" testen musste, einspart. Und ich finde, dass diese Pillepalle Beispiele bei Unittests gar nicht so weit von der Praxis entfernt sind, da man dort nunmal sehr isoliert und kleinschrittig testet. Das muss man aber am Anfang erstmal in den Kopf bekommen, da man oft schon in Gedanken den untestbaren Softwareklump, den man meist historisch gewachsen vorliegen hat, verinnerlicht hat.

[Rollo62]

Schade das es da keine fertigen Rezepte gibt.

Dann wären UnitTests also immer die erste Grundlage.

Diese können aber nicht unbedingt zusammen mit asynchronen, externen Tests integriert werden,
wie z.B. Click-Tests für das Simulieren von UI-Forms, oder physikalische Simulationen zum Testen von Sensorsignalen.

Vom Testablauf müssen dann erstmal die UnitTests laufen, das ist klar.
Und weitere Tests / Simulationen wären on-top, und nicht unbedingt Teil EINES UnitTests.

Man könnte aber z.B. externe Test-Ergebnisse von UI-Click Tests o.ä. mit in die UnitTests integrieren,
so das es erst ein UnitTest OK gibt wenn auch alle Ergebnisse stimmen.
Es spräche dann aber dagegen das UnitTests möglichst auch schnell und unabhängig sein sollten, denke ich.

Ich habe mich leider noch nicht tiefer mit dem beschäftigt was Idera da noch in Richtung Testing anzubieten hat (Ranorex, Gurock, etc.) :oops:
Es könnte aber etwas für mich dabei sein.

[dummzeuch]

Zitat:

Zitat von Rollo62 (Beitrag 1450163)

Vielleihct hängt die mangelnde Akzeptanz von Unit-Tests auch damit zusammen das man den Zusammenhang und die Lösung von "Hello World" zu echten Problemen nur schwer erkennen kann.

Falls jemand gute Hinweise hat wie man solche komplexeren Strukturen noch besser Entwickeln und Testen sollte, immer her damit.

Solche komplexen Systeme werden nicht mit Unit-Tests sonder mit Integrationstests getestet. Und die sind ein ganz anderes Kaliber, wie Du schon selbst schreibst.

Den Spass mit der Kommunikation mit parallel entwickelten externen (embedded) Systemen habe ich immer wieder. Ich schreibe mir dann immer Emulatoren bzw. Simulatoren.

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1450189)

Ich habe mich leider noch nicht tiefer mit dem beschäftigt was Idera da noch in Richtung Testing anzubieten hat (Ranorex, Gurock, etc.) :oops:
Es könnte aber etwas für mich dabei sein.

Wir verwenden TestComplete, was den Vorteil hat, dass man bei in Delphi geschriebenen Programmen auf die Properties usw. von Fenstern und deren Elementen zugreifen kann usw., zudem kann man dort viel mit Skripten machen. Man kann zum Beispiel auch im Skript direkt die Delphi-Objektnamen zum Zugriff auf die Elemente eines Fensters verwenden.

[Rollo62]

Nochmal zu dem Thema.
https://www.code-partners.com/testin...anorex-studio/

Ranorex sieht doch gar nicht schlecht aus ...

[technomage77]

Hallo,

ich bekomme beim Erst-Compilieren eine Fehlermeldung "[dcc32 Fataler Fehler] Project1.dpr(16): F2613 Unit 'DUnitX.Loggers.Console' nicht gefunden." (Youtube 5:14). Ich nutze RAD Studio Delphi 10.4 Sydney in der 'Professional with Mobile'-Edition. Andere Kollegen meinten, dass DUnitX nur in der Architect-Edition verwendet werden kann. Allerdings habe ich wie im Video DUnitX 'DUnitX_IDE_Expert_Sydney.bpl' von Git-Hub und TestInsight installiert.

Gibt es Erfahrungen mit dem Fehlen der DUnitX.Loggers.Console?
Stimmt die Erfahrung meiner Kollegen, dass man DUnitX nur in der Architect-Edition richtig verwenden kann?

Danke.

[generic]

Zitat:

Zitat von technomage77 (Beitrag 1479227)

Stimmt die Erfahrung meiner Kollegen, dass man DUnitX nur in der Architect-Edition richtig verwenden kann?

Nein, die DUnitx funktioniert mit allen Versionen.

Hast du die DunitX runtergeladen und installiert z.B. von hier https://github.com/VSoftTechnologies/DUnitX ?

Die Datei ist dort mit drin: https://github.com/VSoftTechnologies...rs.Console.pas

ggf. sind deine Suchpfade nicht richtig.

Die BPL sind nur Erweiterungen der Delphi-IDE welche paar neue Knöpfe hinzufügen, so dass du z.B. eine leere Unit mit DUnitX rumpf bekommst.