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

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
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 von Uwe Raabe:

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

Ok, naja, dann eben herzlichen Dank an euch Beide

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.

[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 von 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.

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.