Unit tests für JCL/JVCL

[TurboMagic]

In einem anderen Thread hier:
https://www.delphipraxis.net/205011-...ml#post1471149

hat das geschätzte Forenmitglied Stevie die Frage nach Unit Tests für JCL/JVCL aufgeworfen.

Das bringt mich zu verschiedenen Fragen:

1. Ja, wie müsste man Unit Tests für diese immer noch häufig genutzten Bibliotheken aufsetzen?

2. Zumal diese ja immer noch Uralt Delphi Versionen bis D6 unterstützen.
(ich persönlich hätte da schon länger mal D2009 als neue Untergrenze angesetzt wegen Unicode)
Man kann die Nutzerschaft meiner Meinung nach ruhig mal zum Update auf neuere Versionen animieren,
auch wenn es für manche der Projekte etwas Umstellungsaufwand durch die Unicode Migration
bedeuten würde. Da aber auch die IDE, trotz aller momentan vorhandener Probleme, doch einiges
dazu gelernt hat seit D6/D7 kann sich das alleine deshalb schon lohnen. Muss aber jeder selber wissen.

3. Was als Testframework benutzen? DUnit was schon seit < D2009 dabei ist oder DUnitX, welches derzeit
keinen schönen GUI Testrunner hat (Ja, Stevie's Testinsight ist eine Alternative dafür)?

4. Wie die Tests in die Ordnerstruktur einfügen und wie die Tests organisieren? EIne Unit-Test Unit pro
zu testender Unit oder pro zu testender Klasse?

5. Namenskonvention?

6. Wie die Testabdeckung messen?

7. Und wie im Delphi Umfeld generell mehr Leute vom reinen Konsumieren zum Mitmachen bei vorhandenen
oder neuen Open Source Projekten animieren?
Wie man z. B. an diesem Thread sieht:
https://www.delphipraxis.net/205039-....html#poststop
gibt es durchaus Leute die bereit sind etwas beizusteuern, aber evtl. einfach für einen Start etwas
"Händchenhalten"/Anleitung durch die Community benötigen.

=> es müssen ja nicht immer ewig komplexe/zeitaufwändige Beiträge sein, manchmal hilft es schon XMLDOC
Dokumentation zu nicht gleich verständlichen Methoden die man selber aber gut genug kennt beizusteuern
oder kleinere Anpassungen oder eben einen Unit Test für eine Methode deren Verwendung mal selber
"Erforscht" hat und sich dann denkt: naja, hätte ich einen Unit-Test dazu gehabt, hätte ich die
Funktionsweise viel schneller verstanden. Oder im entsprechenden Bugtracker beim Auftauchen neuer
Bugmeldungen die nicht gleich klar sind mal beim Einreicher nach den vermutlich noch wünschenswerten
Informationen nachhaken, damit das nicht auch noch die Zeit der eigentlichen Bibliotheksentwickler
kostet. Dem Einreicher ist manchmal nicht klar, was er noch an Infos liefern soll, einem ausenstehenden
Leser aber schon, da er meist nicht ganz so tief in der Materie drin ist wie der Einreicher.

Grüße
TurboMagic

[Stevie]

Gute Fragen - mal kurz meine Gedanken dazu:

Wie schon im anderen Thread gesagt und das hat nix mit JCL/JVCL zu tun: einfach anfangen.

Oftmals werden keine Tests geschrieben, weil sich keiner traut einfach einen zu erstellen. "Ach, das werden wir eh nie alles testen können. Und was ist mit der Testabdeckung, wie stell ich sicher, dass wir auch alles testen?" Klar, nur weil man dreieinhalb Tests geschrieben hat kann man sich nicht zurücklehnen und denken, nun gibt's keine Defekte mehr. Aber grad wenn man an etwas rumschraubt, find ich persönlich Tests unglaublich nützlich. Die dienen allgemein ja nicht der Bestätigung, wie viele grüne Haken man produzieren kann, sondern der Sicherstellung, dass Änderungen nix kaputt machen.

Klar, mit CI und allem Komfort ist das natürlich am ende richtig geil, aber hier würd ich einfach klein anfangen - man fast was an (ja, visuelle Komponenten sind so ne Geschichte für sich, nicht visuelles lässt sich viel einfacher testen, also evtl erstmal da beginnen, da gibt ja die JCL schon ne Menge her und JVCL hat auch genug nicht visuelles).

Wenn du auf 2009 oder eher bleiben willst würd ich nach wie vor DUnit empfehlen, DUnitX geht erst ab XE oder höher - meiner persönlichen Meinung bietet das auch keinen Mehrwert, den man hier unbedingt bräuchte. DUnit hat alles, was man braucht und kann auch ohne TI mit der UI betrieben werden.

In Verbindung damit würde ich auch mal schauen, ob man in dem Repo ein bisschen aufräumen kann, da liegt noch so viel alter Schrott rum, da kann bestimmt einiges von in die Tonne - das ist im git, da darf man auch mal was löschen, was nicht mehr benötigt wird ;)

[Der schöne Günther]

Punkte 3-6 sollten eigentlich von den Maintainern des Projektes (JCL) vorgegeben werden.

Und ich will es nicht schlechtmachen, aber dass die Jungs seit Jahren nicht einmal mehr Versionsnummern für den veröffentlichten Kram machen sondern jeder halt noch irgendwas committet hat mich wirklich von der JCL weggetrieben.

Vielleicht bin ich ein Weichei, aber mir fällt es schon super schwer, bei Tests für eine Bibliothek die noch bis Delphi XE laufen soll irgendwie mit dabei zu bleiben. Ich kann doch nicht ernsthaft ein Dutzend verschiedene Versionen installieren? Bis wie weit die JCL den Anspruch hat runterzugehen will ich lieber gar nicht wissen...

[freimatz]

Die unit-tests müssten ja nicht unbedingt mit allen Version. Es würde IMHO reichen, dass die mit der jeweils neuesten Delphi Version tun.

[Stevie]

Zitat:

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

Vielleicht bin ich ein Weichei, aber mir fällt es schon super schwer, bei Tests für eine Bibliothek die noch bis Delphi XE laufen soll irgendwie mit dabei zu bleiben. Ich kann doch nicht ernsthaft ein Dutzend verschiedene Versionen installieren? Bis wie weit die JCL den Anspruch hat runterzugehen will ich lieber gar nicht wissen...

Gut, du meinst nun Tests, die auch sicher stellen, dass es auf *allen* unterstützten Delphiversionen läuft - so weit war ich hier noch gar nicht - meine flapsige Aussage, die den Stein hier angestoßen hat, bezog sich auf eine Änderung, deren Korrektheit nix mit der Delphiversion zu tun hat.

Ich stimme dir aber zu, dass open source Entwicklung und Qualitätsicherung für alle unterstützte Versionen und Platformen in Delphi eine riesengroße "pita" ist. Und das sag ich als jemand, der in seinen Bibliotheken derzeit "nur" bis XE runter supported.

[dummzeuch]

Solange sich keiner findet, der das macht, wird nichts passieren. Die aktuellen Maintainer machen immernoch einen guten Job, aber auch ihre Zeit ist vermutlich begrenzt.

Ich persönlich habe nach der Migration zu github nichts mehr beigetragen (vorher hatte ich Schreibrechte auf das SVN Repository auf Sourceforge), aber wirklich Zeit dafür hätte ich sowieso nicht.

[TurboMagic]

Danke schon mal für diese konstruktive und lebhafte Diskussion!

Ja, Tests können sich ruhig auf die neueste Version beschränken!
Ich mach' das in der DEC https://github.com/winkelsdorf/Delph...tionCompendium

Dass gewisse Punkte von den Maintainern vorgegeben werden sollten kann ich einsehen,
ich trete auch dort im Forum mal eine Diskussion los.

Und ja: irgendwer muss mal irgendwie anfangen.
Ich kenne mich in JCL/JVCL jedoch auch nicht gerade gut aus, auch wenn ich letztes Jahr den einen
oder anderen Bug gefixt habe und beim Update der Unicode Definitionen mitgewirkt habe.

=> was wäre eine Ecke dieser Projekte wo man mal ohne zuviele Vorkenntnise ein paar einfache Tests
umsetzen könnte um einen Anfang zu machen?

[TurboMagic]

Siehe hier, Thema vom 5.8.2020, kann scheinbar nicht direkt da hin verlinken:
https://newsportal.delphi-jedi.org/t...p=jedi.general

[TurboMagic]

Nach dieser Aussage aus dem Jedi-Forum hier aber mal gleich ran an die Arbeit: ;-)

> Hi,
>
> There are some existing units in
> https://github.com/project-jedi/jcl/...utomated/dunit
>
> But they have not been updated for years...

[himitsu]

Zitat:

ich persönlich hätte da schon länger mal D2009 als neue Untergrenze angesetzt wegen Unicode

Was sich nicht auschließen muß.

Klar, es gibt einen Mehraufwand, oder auch nicht.
Man könnte solche Projekte auftrennen.
* eine/mehrere Legacy-Version für ältere Delphis
* und eine aktuelle Version, wo man den alten "Mist" endlich entsorgen kann

* die Alte z.B. für ANSI (2007 und davor)
* vielleicht auch schon noch später den Cut -> z.B. ab 10.x, bzw. ab einer der späteren XEs
* und eine bereinigte aktuelle Version ohne jeglichen alten Code (abgesehn von neuerem "AltCode" für aktuellere "alte" Versionen)

-

* beim neuen Code wird es einfacher, ohne Altcode oder durch Nutzung neuer Compiler-Features und Units
* teilweise muß man dann eben die alten Versionen zusätzlich (doppelt) pflegen, wenn man gewisse Dinge nicht mehr direkt zurück portieren kann
** aber die zusätzliche Zeit hat man ja beim Neuen vermutlich schon gespart ... und eventuell muß man auch nicht alles zurück patchen, bzw. irgendwann auch garnicht mehr (im Ernstfall friert man die alten Versionen dann irgendwann/sofort ein)


Die Alternative wäre den Cut andersrum zu machen (aber braucht verdamt viel Zeit)
* ein neues Projekt anfangen, da eine "hohe" Mindestversion ansetzen und dann stück für stück Codes vom Alten nehmen, aufräumen/modernisieren, ins Neue einfügen und direkt gleich die Tests dazu

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1471249)

* eine/mehrere Legacy-Version für ältere Delphis

Entspricht das nicht gerade dem aktuellen Stand? Wenn man den als ZIP bereitstellt, kann auch in Jahren noch jeder die Library für sein Delphi 7 oder so einsetzen.

Durch den Wegfall des Supports für ältere Versionen wird doch niemandem etwas weggenommen - halt nur nichts mehr dazugefügt.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1471250)

halt nur nichts mehr dazugefügt

Was aber auch Bugs betreffen könnte, die man erst jetzt/später entdeckt. (oder wo seit Jahren niemand Lust zu hatte)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1471251)

Was aber auch Bugs betreffen könnte, die man erst jetzt/später entdeckt. (oder wo seit Jahren niemand Lust zu hatte)

Willst du damit andeuten, die Entwickler würden Bugs über Jahre ungefixt lassen? Entwickler, die selbst entscheiden können, ob sie die Bugs fixen oder nicht? Ich bin zutiefst erschüttert :shock:

[TurboMagic]

Naja, wnen ich mir manche der Bugreports ansehe sind die auch nicht immer so,
dass man gleich was damit anfangen kann und dann reagieren die Erfasser manchmal auch nicht auf Rückfragen.

Aber ja, bei OpenSource Projekten wie diesem können die Entwickler tun und lassen was sie wollen... ;-)

[TurboMagic]

Tata: ein erster Start:

Hier ein Pull Request für erste Unit Test bezogene aktivitäten in der JCL:
https://github.com/project-jedi/jcl/pull/85

Weitere Mitstreiter(innen)/Helfer(innen) sehr willkommen! ;-)

Da es ja für die JCL schon definiert ist wo die Tests hin sollen (unterordner qa etc.) könnte ja jetzt
mal jemand mutig sein, und in der JVCL anfangen! ;-)

Grüße
TurboMagic

[TurboMagic]

Tja, kaum gestartet, schon gibt's Probleme:
Beim Versuch Compiler Warnungen zu beseitigen in TestJCLStrings bin ich
über

Delphi-Quellcode:

procedure TAnsiStringListTest._SetDelimitedTextFunkyFalse;

gestolpert. Da soll wohl die Korrektheit einer AnsiStringList der JCL geprüft werden,
nur ist die TStringList mit der teilweise verglichen wird ja ab D2009 Unicode.
Ist der Test noch so gültig?

Das trifft wohl auf die ganze Unit zu, da die wohl lauter Ansi strings erwartet.

[TurboMagic]

Und hier die nächsten Probleme:

In TestJclMath sind einige leere Testmethoden schon mal deklariert, aber noch nicht ausprogrammiert.
Eine davon konnte ich so wie eine bereits bestehende ausfüllen, aber diese beiden hier wollen nicht
so recht, dummerwise bin ich aber auch kein Mathe-Genie:

Delphi-Quellcode:

procedure TMathTranscendentalTest._ArcCsc;
var
  x: Extended;

begin
  x := -3.98;

  while x < -1 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;

  x := 1.00;

  while x < 4 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;
end;

Die _ArcCsc meckert, dass die Ergebnisse nicht übereinstimmen, obwohl beide verglichenen
Ergebnisse lt. DUnit log-Eintrag identisch sind. Da muss wohl der Fehler noch weiter hinten
in den Nachkommastellen liegen...

PrecisionTolerance: Float = 0.0000001;
Und Log-Meldung: expected: <-0,253977954770906> but was: <0,253977954770906>

Habe jetzt eben erst gesehen, dass das Vorzeichen falsch ist und ein Vergleich von Math.ArcCsc und JclMath.ArcCSc ergibt:
System.Math: Result := ArcSin(1 / X);
JclMath: Result := ArcSec(X / Sqrt(X * X -1));

Wer hat recht?

[TurboMagic]

Und ArcSec Test der analog zum ArcCsc von mir umgesetzt wurde läuft auch auf einen Fehler und hier
wird das auch in System.Math und JclMath unterschiedlich implementiert, wobei JclMath sogar die
Implementation von System.Math benutzt, wenn ein gewisses Define gesetzt ist.

JclMath: FArcTan(Sqrt(X*X - 1)); aber in ASM programmiert
System.Math: Result := ArcCos(1 / X);

Warum ist die Umsetzung in der JCL so anders?

[Rollo62]

Von der Jcl/JVcl bin ich über die Jahre ziemlich weggekommen.
Mein Eindruck war und ist dass dies ein unzusammenhängendes Sammelsurium aus mehr oder weniger Zuverlässigen und Unzuverlässigen Quellen ist.

Das sind ein paar Diamanten drin, aber IMHO auch viel Müll.

Würde es nicht Sinn machen zuerst mal die Spreu vom Weizen zu trennen,
und alte Zöpfe rauszuwerfen, oder zumindest separat zu trennen ?

Ein Neustart der Jedi könnte dem ganzen neues Leben einhauchen, denke ich.

Wer ist denn eigentlich genau zuständig für die Jedis, müssen da nicht Alle zustimmen, oder ist das Projekt schon verwaist ?
wie gesagt, ich hatte das schon seit Jahren ad Akta gelegt.
Sorry für die blöde Frage :stupid:

[TurboMagic]

Hallo,

die Fragen sind nicht so blöde.

Es gibt noch Maintainer die Pull requests begutachten und commiten und dafür sorgen,
dass es mit der jeweils neuesten Delphi Version immer noch funktioniert.

Nur: wo was abschneiden? Wer nutzt was und was ist wertvoll genug um es aufzuheben?
Wieviel Gemecker gibt es, wenn man irgendwas entfernt, dass jemand benutzt hatte
der nun seinen Code ändern muss?

Also ich wäre schon mal dafür, dass man die mindestens benutzte Delphi Version mal
endlich von D6 "wegbewegt"! Zum Beispiel auf D2009 oder noch besser XE2 oder so,
wo die Generics dann mal anfingen soweit brauchbar zu werden.
Es bräuchte halt dann mehr Leute die sich wirklich dran beteiligen, denn wie du schriebst:
es sind auch ein paar wirklich nützliche Sachen drin!

Grüße
TurboMagic

[Rollo62]

Ich könnte mir vorstellen das man die Jedis splittet,
vielleicht in zwei Projekte.
Eins mit den guten Teilen, und eins darauf aufbauend mit dem Müll.
So können die welche die schlechten Teile nutzen noch weiterarbeiten,
wissen aber das diese nicht mehr viel gepflegt wird.

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Vielleicht bin ich der Einzige der so denkt :stupid:

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

[TurboMagic]

Hallo,

deine Idee ist grundsätzlich nicht verkehrt, aktuell bin ich aber ein bisschen an der JCL,
da gibt's ja keine Komponenten.

Ich hab' z. B. vorhin deren Unicode Support auf v13 aktualisiert, aber mich mal wieder in Git
verheddert und somit einen Pullrequest fabriziert, der zuviele Dateien enthält. Keine Ahnung
wie ich die wieder rausbekomme oder ob das einer der Maintainer machen muss...

Grüße
TurboMagic

[TurboMagic]

Zitat:

Zitat von Rollo62 (Beitrag 1471346)

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

So, ich hab da mal was anderen ortes geschrieben:
https://newsportal.delphi-jedi.org/t...p=jedi.general

Es dürfen sich dort gerne alle einbringen, d.h. mitdiskutieren.
Wer's nicht kennt: das oben verlinkte ist das Webinterface zu den klassischen NNTP Style Newsgroup vom JEDI Projekt.

[Stevie]

Zitat:

Zitat von TurboMagic (Beitrag 1471348)

Keine Ahnung wie ich die wieder rausbekomme

Wenn du im Unicode_V13_Support branch bist:

git rebase onto <commit vor dem, den du behalten willst> <commit auf dem dein commit basieren soll>
Sollten die commits, die du behalten willst und die du entfernen möchtest, vermischt sein:
git rebase -i <commit vor dem ersten commit, den du anpassen/entfernen willst>


Dann git push --force

Pullrequest wird automatisch aktualisiert

[TurboMagic]

Zitat:

Zitat von Rollo62 (Beitrag 1471346)

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Vielleicht bin ich der Einzige der so denkt :stupid:

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

Es gibt dazu hier inzwischen eine Diskussion:
https://newsportal.delphi-jedi.org/t...p=jedi.general

Ruhig mal teilnehmen, entweder per Newsreader (z. B. Thunderbird, Xananews oder was auch immer) oder über das Web Frontend.

[TurboMagic]

Danke mal dafür.
Ein paar der Pullrequests konnte ich dadurch reparieren.
Ein paar aber nicht, die sagen jetzt was von Konflikten.

Siehe z.B. meine Konversation hier:
https://github.com/project-jedi/jcl/pull/91

Grüße
TurboMagic

[Stevie]

https://docs.github.com/en/github/co...e-command-line

Alternativ eins der gängigen UI Tools für Git verwenden, z.B. Fork und das Difftool deiner Wahl, dann geht das auch einfach von der Hand.