DUnitX mit TestInsight für MemoryLeaks konfigurieren

[Rollo62]

Hallo zusammen,

ich habe DUnitX mit TestInsight am Laufen, geht auch auf allen Plattformen.
Aber die MemoryLeaks-Beispiele bekomme ich nicht ans Laufen, oder verstehe ich das falsch ?

Ich müsste doch mit DUnitX auch MemoryLeaks wie AllocMem(123); als Fehler gemeldet bekommen, oder nicht ?

Ich setze in den Fixtures noch die Atteribute, obwohl eigentlich überflüssig.

Delphi-Quellcode:

  [TestFixture]
  [IgnoreMemoryLeaks(False)]  // Report all leaks. This is the same as not specifying this attribute.
  TDunitX_MemLeakTest = class(TObject)
  ...
  ...

Was mache ich falsch ?

Rollo

[alda]

Memoryleaks können mit DUnitX nach meinem letzten Stand nicht wirklich ermittelt werden (siehe Issue #111 auf Github).

[Rollo62]

Ok, naja. Zu früh gefreut.
Hatte nur die Tests gesehen, und festgestellt das es nicht geht.

Suche den Fehler natürlich immer zuerst bei mir :pale:

Und wenn würde ich die MemoryLeaks-Suche auch in erster Linie für Android, iOS benötigen.
Hast du da einen Tipp für mich ?

Rollo

[Der schöne Günther]

Ich habe es immer noch auf der Agenda und bislang nicht im Detail angeschaut. Was ist eigentlich das hier:

https://bitbucket.org/shadow_cs/delphi-leakcheck/

?

[Stevie]

Zitat:

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

Ich habe es immer noch auf der Agenda und bislang nicht im Detail angeschaut. Was ist eigentlich das hier:

https://bitbucket.org/shadow_cs/delphi-leakcheck/

?

Ein MemoryManager für genau das: Detailiertes MemLeak Reporting während des Testens - haben es im Einsatz (sowohl an der Arbeit, als auch bei Spring4D) und es funktioniert hervorragend.
Allerdings nutzen wir nach wie vor DUnit mit Attributes Support.

[Rollo62]

Hallo Stefan,

also DUnit statt DUnitX ?
Was ist denn jetzt die Richtige Entscheidung.
Bin extra auf DUnitX eingestiegen weil ich dachte das ist der beste, modernste Weg für alle Aufgaben.
Ist DUnit denn evtl. besser unterstützt, oder wird DUnitX das DUnit bald verdrängen ?

Rollo

[alda]

Zitat:

Zitat von Rollo62 (Beitrag 1338781)

Und wenn würde ich die MemoryLeaks-Suche auch in erster Linie für Android, iOS benötigen.
Hast du da einen Tipp für mich ?
Rollo

Wenn es Dir hauptsächlich um die Leaks geht wirst Du um DUnit vermutlich nicht herumkommen (hier funktioniert die Leakdetection auf Testebene). Mit Stefans Attribut-Support für DUnit natürlich nicht zu verachten. Ich selbst nutze ausschließlich DUnitX und lasse mir Memoryleaks lediglich mit den madExcept tracken. (wobei ich auch nur für Windows entwickle).

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1338844)

Hallo Stefan,

also DUnit statt DUnitX ?
Was ist denn jetzt die Richtige Entscheidung.
Bin extra auf DUnitX eingestiegen weil ich dachte das ist der beste, modernste Weg für alle Aufgaben.
Ist DUnit denn evtl. besser unterstützt, oder wird DUnitX das DUnit bald verdrängen ?

Rollo

DUnitX wird "aktiv" entwickelt (so viel Zeit hat Vincent dafür allerdings auch nicht) und wurde afaik mehr aus der Not heraus geboren, da Teile von DUnit doch arg verwurschtelt sind.
Außerdem gab und gibt es derzeit keinen offiziellen Maintainer von DUnit, so dass das mehr so vor sich hingammelt, Embarcedero hat bei der Version, die sie mit ausliefern einiges modifiziert, was afair nicht irgendwo zurückgeflossen ist (aus vorherig genanntem Grund).

Ich persönlich vermisse in DUnit durch meine eigenen Erweiterungen (Link im vorherigen Post) nichts, was DUnitX bietet.
Mir macht es nichts, wenn ich von TTestCase (oder einer eigenen davon abgeleiteten Klasse) erben muss und mir fehlt auch kein Fixture Setup/TearDown.

DUnit wird von vielen leider missverstanden und aufgrund der etwas unglücklichen Benamung (GUI oder Text/Console Runner sind eigentlich keine Runner sondern Listener),
denken viele, dass das darunter liegende Framework daran gekoppelt ist, was allerdings nicht stimmt.

IMO ist es tausendmal wichtiger, dass man überhaupt Unit/Integrations Tests mit einer entsprechenden Abdeckung durchführt, als welches Framework man nutzt.

[Rollo62]

Ja danke für die Info.
Werde wohl bei DUnitX bleiben, finde ich auch sympatischer,
in der Hoffnung das LeakCheck bald mal auf der Agenda steht.

Solange muss ich mich mit Instruments und anderen Dingen durchwurschteln.

Problematisch ist das eben nur bei Fremdcode, bei mir gibt es z.B. Leaks when ich den RadDemo BLEScanner verwende
mit FilterParametern.
Sobald der die Services verbindet kommen MemoryLeaks, baer leider nur mir NSString Info.
Schwer zu sagen obs vom Demo oder vielleicht sogar vom Framework kommt.

Noch kann ich damit Leben, weils nur ein paar Bytes sind,
falls wenn das jemals Apple mitbekommen sollte gibts bestimmt Ärger.

Rollo