Delphi-Unit-Tests project

[Rollo62]

Hallo zusammen,

beim Stöbern habe ich gerade zufällig etwas Neues von Uwe Raabe gefunden (oder hab ich da was verpasst ?).
Genau sowas hatte ich schonmal vorgeschlagen, um allgemeine (und sehr spezielle) Delphi-Typen zu Testen,
auf ungewünschte Änderungen bei neuen Versionen.

Jetzt hat sich Uwe dankenswerterweise erbarmt mal so ein Projekt bei Github einzustellen,
herzlichen Dank dafür :thumb:

Ich werde mir das mal genauer ansehen, und hoffe das auch ansonsten noch recht Viele dazu beitragen werden,
um möglichst viele UnitTests für Delphi/FMX aus allen Richtungen da unterzubringen.
Damit sollte man Festzustellen können wenn neue Delphi-Versionen oder Updates, oder auch 3rd Party Teile da reinpfuschen, und Delphi mal wieder hakelt.
Ich denke Tests von sehr profan bis hochspeziell, Alles macht an der Stelle Sinn, um ungeplante Änderungen schnell entdecken zu können,
und Verursacher zu identifizieren.
Auch um zu entdecken wann bekannte Fehler plötzlich gefixt werden.

Hallo Uwe, ich hoffe Du bist auch auf rege Beteiligung an dem Projekt vorbereitet :stupid:
Also meine Unterstützung hast Du dafür.

[Uwe Raabe]

Das ist gar nicht mein Projekt! Es war vielmehr Nick Hodges, der das schon vor einigen Jahren zu seiner Zeit bei CodeGear ins Leben gerufen hat. Leider ist es dann dem Sunset für Mercurial bei Bitbucket zum Opfer gefallen. Als an anderer Stelle nach den Sourcen für das Projekt gefragt wurde, konnte ich mit einem Clone aushelfen. Dabei habe ich dann gleich eine Portierung nach GitHub vorgenommen.

[dummzeuch]

Hm, im readme.md wird auf das Projekt-Wiki verwiesen, aber das scheint leer zu sein. Oder bin ich nur zu blöd es aufzurufen?

[Uwe Raabe]

Die Readme.md ist aus dem ursprünglichen Bitbucket-Projekt unverändert übernommen worden. Vermutlich gab es dort noch ein Wiki. Das das aber beim Clone des Repos ja nicht mitgenommen wird, ist das vermutlich verloren.

Es gibt auch ein Repo von Nick selbst (https://github.com/NickHodges/DelphiUnitTests) aber da fehlt die ganze Historie.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1497341)

Das ist gar nicht mein Projekt! Es war vielmehr Nick Hodges, ...

Ok, naja, dann eben herzlichen Dank an euch Beide :thumb:

Ich sehe bei Nick es ist gerade 6 days ago ... bis XE6
Bei Dir ist es 5 days ago, aber auch was mit 8 years ago ... ebenfalls bis XE6

Wer hat das Rennen denn jetzt gewonnen ?

Ich hoffe nicht dass es jetzt zwei konkurrierende Repositories gibt, wie schon so oft.
Ist denn da die Pflege und Aktualisierung, bis Rx11, bei Dir überhaupt angedacht ?
Oder ist das nur für deine internen Zwecke gedacht.

[Uwe Raabe]

Die Repos enthalten aktuell den gleichen Stand.

Anfangs konnte Nick das Repo nicht wiederfinden und fragte, ob jemand eine Kopie bereitstellen könne. Dann fand er wohl doch noch eine Kopie bei sich, die er in GitHub hochlud. Da dort aber die Historie komplett fehlte, habe ich meinen letzten Stand auch in GitHub verfrachtet und seine letzten Änderungen nachgezogen. Es war mir einfach wichtig, die frühere Arbeit der Beteiligten nicht anonym werden zu lassen.

Pssst! Eigentlich sind diese und auch zukünftige Tests für Embarcadero bestimmt - aber nicht weitersagen.

[venice2]

Zitat:

Pssst! Eigentlich sind diese und auch zukünftige Tests für Embarcadero bestimmt - aber nicht weitersagen

Ich schweige wie ein Grab. :-D

[TurboMagic]

Ok, wir wissen jetzt zwar, warum es zwei Repositories gibt, aber das Problem ist damit nicht aus der Welt.
Meiner Meinung nach:

1. Sollten sich Uwe und Nick einigen welches weiter bearbeitet werden sollte

2. In beiden Repositories sollte in der Readme drin stehen welches das weiter zu bearbeitende drin ist,
ggf. mit Link auf das andere welches bearbeitet werden sollte.

3. Die Tests sollte mal jemand mit 11.0 ausprobieren und dokumentieren ob's damit irgendwo hakt.

4. Es sollten möglichst viele dann Tests beisteuern...

5. Man sollte die Tests so aufsetzen, dass man auch gut mit TestInsight arbeiten kann.
Wer wissen will wie man sowas machen könnte darf sich mal die DUnit dpr aus dem DEC DUnit
Test hier anschauen: https://github.com/MHumm/DelphiEncryptionCompendium

6. Sollte diese TestInsight Unterstützung eingebaut werden, sollte die Readme das auch dokumentieren.

Grüße
TurboMagic

[Uwe Raabe]

Ich sehe nicht dass TestInsight hier überhaupt relevant ist. Die Tests sind als Regressiontests für RTL, VCL und Co. gedacht und sollen im Idealfall in deren Testsuite integriert werden. Diese wird aber im Build-Prozess ausgeführt und nicht innerhalb der IDE.

Natürlich kann jeder das für sich auch mit TestInsight machen.

[TurboMagic]

Zitat:

Zitat von Uwe Raabe (Beitrag 1497399)

Ich sehe nicht dass TestInsight hier überhaupt relevant ist. Die Tests sind als Regressiontests für RTL, VCL und Co. gedacht und sollen im Idealfall in deren Testsuite integriert werden. Diese wird aber im Build-Prozess ausgeführt und nicht innerhalb der IDE.

Natürlich kann jeder das für sich auch mit TestInsight machen.

Ich sehe das anders. Die Tests werden ja nicht nur im Build Prozess für RTL usw. ausgeführt, sondern beim Entwickeln weiterer Tests auch von den Entwicklern in der IDE und wenn die dort dann im Hintergrund laufen können ist das vorteilhaft. Der Aufwand dazu ist ja auch gering.

[Uwe Raabe]

Da hast du allerdings Recht. Dann lass es mich so formulieren: Mir ist lieber, jemand schreibt einen Test ohne TestInsight (warum auch immer) als gar keinen Test.

[TurboMagic]

Ja, das ist natürlich lieber, aber man kann es trotzdem integrieren um das zu vereinfachen.
Die Nutzung davon bleibt optional. Schau dir doch einfach die dpr des DUnit Test Projektes der DEC an,
dann siehst du wie's umgesetzt ist.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1497399)

Diese wird aber im Build-Prozess ausgeführt und nicht innerhalb der IDE.

Das kann man so machen.
Vom Ablauf her, sehe ich das aber besonders dann als interessant an,
wenn man die IDE-Version wechselt/installiert/patched, oder irgendwelche 3rd Party Tools installiert.
Immer dann macht ein Test EINMAL in der IDE Sinn, um dann auch gleich mit TestInsight die Ursache zu erforschen.
Danach "sollte" ja Alles stabil bleiben.

Ist eine Version dann mal stabil, dann braucht man die eigentlich nicht mehr in der IDE, das stimmt.
Aber es sollte sich ja auch nichts mehr ändern, also bräuchte man es auch nicht in JEDEM Build-Prozess.

Trotzdem hatte ich öfters Fälle wo die im Debugger einfach IDE System-Files öffnet und ändert,
und dann beim Schliessen fragt ob man das Speichern möchte.
Wenn man dann im Eifer die falsche Taste "JA" drückt könnte man SystemFiles ungewollt ändern,
und so Bugs reinbauen.

Da hast Du dann Recht das diese Tests dann auch in jedem Build Sinn machen können.

[Stevie]

Die Tests selber haben nix mit TestInsight zu tun. TestInsight ist nur ein Listener für die unterstützten TestFrameworks und hat Null mit den Tests an sich zu tun.
IMO ist hier ein bisschen Mitarbeit von Embarcadero wünschenswert - ich bin nämlich gar nicht sicher, wie deren Unittest/CI Setup aussieht und ob das DUnit(X) nutzt oder irgendwas selbstgetüfteltes - zumindest tauchten früher oft in den QC und QP Reports immer Snippets auf, die auf ein anderes Format hinwiesen. Wenn die nämlich nicht einfach die Tests nehmen können/wollen und sie in ihr CI kippen, dann ist das ganze Projekt witzlos.

[Rollo62]

Zitat:

Zitat von Stevie (Beitrag 1497467)

... dann ist das ganze Projekt witzlos.

Also witzlos würde ich nicht sagen.
Von Emba erwarte ich da nicht viel, weder dass die sich dran beteiligen, noch dass die das Nutzen werden.

Wichtig wäre das für uns, genau aus obigem Grund.
Damit die Entwickler selber Testen können wo etwas kracht, weil es Emba nicht macht.
Das gute, alte DIY Prinzip :stupid:

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1497471)

Damit die Entwickler selber Testen können wo etwas kracht, weil es Emba nicht macht.
Das gute, alte DIY Prinzip :stupid:

Und dann? Im QP reporten, monate- oder jahrelang auf nen Fix warten und derweil rummotzen, warum das denen nicht selbst aufgefallen ist.
Und wenn der Fix dann in einer Version ist, enttäuscht sein, dass man die wegen irgendnem neuen Bug nicht nutzen kann.

Zitat:

Zitat von Rollo62 (Beitrag 1497471)

Von Emba erwarte ich da nicht viel, weder dass die sich dran beteiligen, noch dass die das Nutzen werden.

Und genau das muss sich ändern. Die Community hat inzwischen ihre Erwartungshaltung dermaßen tief gelegt, dass nichmal mehr ne Ameise darunter durch kommt.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1497471)

weil es Emba nicht macht.

Genau das gilt es ja zu verhindern.

[Rollo62]

Tja, die Schere zwischen Wunsch und Wirklichkeit klafft immer weiter auseinander.

Und auch bei dem Scherenvergleichs-Begriff kräuseln sich mir mittlerweile die Fußnägel 2m hoch. :stupid:

DIY ist schonmal besser als nichts, aber Ihr habt natürlich vollkommen Recht.
Immerhin bezahlen wir auch ein paar Penunzen für den ganzen Spaß.
Vielleicht sollte Emba doch mal ein paar sinnvolle Interna als OpenSource rausstellen,
damit die Entwicklung und Bugixes schneller vorangehen können.

Das auch im Hinblick wenn ich mir aus anderen Threads Parnassus, ParallelDebugger, etc. ansehe.
Da kommt Rx11 raus, und ich kann es 2 Monate nicht nutzen weil dies und das fehlt.
Ja, ich habe mich damit mehr oder weniger arrangiert, aber immer wenn ich mal drüber nachdenke ... :evil:

[Uwe Raabe]

Selbst wenn Embarcadero die Tests nicht selbst nutzen sollte (was ich für äußerst dämlich halten würde), können die diversen Early-Beta-Tester diese ja frühzeitig anwenden um Regressions auch zeitnah aufzuspüren.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1497478)

Selbst wenn Embarcadero die Tests nicht selbst nutzen sollte (was ich für äußerst dämlich halten würde), können die diversen Early-Beta-Tester diese ja frühzeitig anwenden um Regressions auch zeitnah aufzuspüren.

Sowas grundsätzliches erst bei den Beta-Testern zu finden halte ich schon für viel zu spät :(

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1497481)

Sowas grundsätzliches erst bei den Beta-Testern zu finden halte ich schon für viel zu spät :(

Genau deswegen wollen wir ja auch, dass die Tests mit in die hauseigene Testsuite aufgenommen werden. Nur haben wir außer der Bereitstellung und Pflege der Tests im Repo keinerlei Einfluss darauf. Wenn es seitens Embarcadero nur sehr geringen Aufwand bedeutet, die Tests einzubinden, dann sehe ich eine realistische Chance.

[freimatz]

[QUOTE=Stevie;1497474]

Zitat:

Zitat von Rollo62 (Beitrag 1497471)

Und dann? Im QP reporten, monate- oder jahrelang auf nen Fix warten und derweil rummotzen, warum das denen nicht selbst aufgefallen ist.

Nach meine Erfahrung mit dem Support interessieren die sich auch nicht für offensichtliche reproduzierbare Fehler.
Und wen nman etwas zeigen will heißt es, dass sie aus rechtlichen Gründen nicht auf unsere PC schauen dürften.

Zitat:

Zitat von Rollo62 (Beitrag 1497471)

Die Community hat inzwischen ihre Erwartungshaltung dermaßen tief gelegt, dass nichmal mehr ne Ameise darunter durch kommt.

Ameise? Nicht mal ein Virus!
Wir in der Firma sind froh wenn man weniger 50% der Arbeitszeit für Delphi-Probleme aufwenden muss. Kollegen benutzen Logging weil das Debuggen mit 64-Bit bei uns immer noch nicht funktioniert (auch nicht mit Delph 11). So hat man vor 30 Jahrne programmiert.

[TurboMagic]

Hallo,

trotzdem alles, was bisher diesbezüglich nicht gemeldet ist, auch melden.
Dann steigen die Chancen auf Bugfixes. Kann dann zwar immer noch dauern aber
ohne Meldung wird's eher gar nix...

Und in Beta Tests hat man manchmal auch Gelegenheiten Dinge auf dem kleinen Dienstweg
gefixt zu bekommen. Also ruhig mal teilnehmen, wenn's wieder Gelegenheit dazu gibt...

Grüße
TurboMagic