Unit tests für JCL/JVCL

[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