Compiler-Schalter in Basis-Units

[Scurra]

Zitat:

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

Ich habe mir das mal angeschaut. Das scheint leider nicht mehr weiter entwickelt zu werden (der letzte angegebene Support ist für Delphi XE7 und der letzte Commit war 2017). Deshalb haben wir uns dazu entschieden, ohne Leak-Checks in Unit tests auszukommen. Notfalls müssen wir ReportMemoryLeaksOnShutdown nach der Implementierung der Tests auskommen.

Trotzdem danke für den Hinweis auf LeakCheck.

[hoika]

Hallo,

Zitat:

Soweit ich weiß, führt ReportMemoryLeaksOnShutDown dazu, dass ein Fenster angezeigt wird mit den Memory-Leaks. Das ist sicherlich geeignet, wenn man die Tests manuell startet. Für einen automatischen Build-Prozess ist das leider nicht geeignet.

Das Fenster müsste ausschaltbar sein, dann wird nur eine Textdatei mit den Leaks erzeugt.

[Stevie]

Zitat von Scurra:

Zitat:

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

Ich habe mir das mal angeschaut. Das scheint leider nicht mehr weiter entwickelt zu werden (der letzte angegebene Support ist für Delphi XE7 und der letzte Commit war 2017). Deshalb haben wir uns dazu entschieden, ohne Leak-Checks in Unit tests auszukommen.

Eure Entscheidung, aber lass dir gesagt sein, dass ihr auf ein wertvolles Werkzeug verzichtet. Wir benutzen LeakCheck mit 10.1 ohne Probleme in unseren Unit- und Integrationstests und auch bei der Spring4D Entwicklung setze ich es mit der neuesten Delphiversion und auch auf anderen Betriebssystemen als Windows ein. Grad wenn man mal nen Leak hat, was durchaus nen ganzer Batzen an Objekten sein kann, ist der Dependency Graph, den Leakcheck bauen kann, unerlässlich, um fix die Ursache zu finden (oder gar zu sehen, dass man eine zirkuläre Referenz hat, wo sich Dinge gegenseitig am Leben halten).