Delphi-Unit-Tests project

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

[Rollo62]

Zitat von Uwe Raabe:

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.