Delphi-Unit-Tests project

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

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

[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 von Stevie:

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