Erfahrungen mit DelphiCodeCoverage und "Delphi Code Coverage Wizards" #1

[Stevie]

CodeCoverage ist leider noch enorm instabil und bei nur dem kleinsten Fehler in der map Datei (da werden manchmal Code Addressen als ausführbarer Code gelistet, die gar nicht stimmen, bzw in die auf gar keinen Fall ein Breakpoint darf) klatscht es gegen die Wand.
Besonders bei Generics (muss ich wohl wissen, hab bereits einige Stunden reingesteckt um einen vollständigen Report für die Spring Tests zu bekommen, der auch korrekt ist) fliegt es sehr oft auseinander.

Aber da ja jüngst irgendwie so ein kleiner Hype um das Projekt ausgebrochen ist, lehn ich mich zurück und warte, bis es jemand fixed.

[freimatz]

Und ich dachte, da ist ein Hype ausgebrochen, das muss ich ausnutzen
Da ich nun auch nicht weiter komme bleibt mir wohl auch nichts weiter übrig als mich diesbezüglich zurückzulehnen. Das das jemand fixed habe ich gerade jedoch wenig Hoffnung.
Wieder ein Grund wieso man mit Delphi nicht professionell Software entwickeln kann.

[Uwe Raabe]

Zitat von freimatz:

Wieder ein Grund wieso man mit Delphi nicht professionell Software entwickeln kann.

Bei solchen Aussagen wundere ich mich immer, wie ich die vergangenen Jahre über die Runden gekommen bin.

Was das CodeCoverage betrifft, sehe ich auch keinen Grund, das im Build-Prozess immer wieder durchlaufen zu lassen. Es genügt doch, dies bei Erstellen oder Anpassen eines Tests zu machen, bzw. bei einer Codeänderung um festzustellen, was danach noch ungetestet ist. Dafür reicht mir eigentlich das hier: https://github.com/UweRaabe/DelphiCodeCoveragePlugin

[Stevie]

Zitat von Uwe Raabe:

Was das CodeCoverage betrifft, sehe ich auch keinen Grund, das im Build-Prozess immer wieder durchlaufen zu lassen. Es genügt doch, dies bei Erstellen oder Anpassen eines Tests zu machen, bzw. bei einer Codeänderung um festzustellen, was danach noch ungetestet ist.

Das ist putzig - bei ner Codebase von Millionen von Zeilen und abertausenden von Unit- und Integrationstests - bei welchem der Tests guck ich dann genau die Coverage nachdem ich Source angepasst habe?
Und übrigens reicht es nicht, wenn an jeder Codezeile nen "wurde ausgeführt" Bömpel dran ist - einfach mal googeln: code coverage of 100 percent is not enough

[TurboMagic]

Zitat von Stevie:

Zitat von Uwe Raabe:

Was das CodeCoverage betrifft, sehe ich auch keinen Grund, das im Build-Prozess immer wieder durchlaufen zu lassen. Es genügt doch, dies bei Erstellen oder Anpassen eines Tests zu machen, bzw. bei einer Codeänderung um festzustellen, was danach noch ungetestet ist.

Das ist putzig - bei ner Codebase von Millionen von Zeilen und abertausenden von Unit- und Integrationstests - bei welchem der Tests guck ich dann genau die Coverage nachdem ich Source angepasst habe?
Und übrigens reicht es nicht, wenn an jeder Codezeile nen "wurde ausgeführt" Bömpel dran ist - einfach mal googeln: code coverage of 100 percent is not enough

Ja, genau genommen reicht das nicht. Aber das zu haben vs. es nicht zu haben ist schon ein Fortschritt!

[Stevie]

Zitat:

Aber das zu haben vs. es nicht zu haben ist schon ein Fortschritt!

Genau deshalb zählt CodeCoverage ja auch die Hits. Was Uwe aber oben als ihm genügend erwähnte soweit ich weiß nicht.

[Uwe Raabe]

Es zählt auch die Hits, wie im unteren Screenshot auf der GitHub-Seite in den eckigen Klammern zu sehen ist. In dem Beispiel wird halt nur ein Test gemacht, deswegen immer nur eine 1. Die roten Pfeile zeigen dabei die Code-Zeilen mit HitCount = 0.

[TurboMagic]

Zitat von Stevie:

Zitat:

Aber das zu haben vs. es nicht zu haben ist schon ein Fortschritt!

Genau deshalb zählt CodeCoverage ja auch die Hits. Was Uwe aber oben als ihm genügend erwähnte soweit ich weiß nicht.

Nur um dich richtig zu verstehen: Was Uwe aber oben als soweit ich weiß ihm nicht genügend erwähnte.
Naja, ihm geht's wohl darum, dass ein C2 oder wie auch immer das genannt wird (lt. Wikipedia gibt's
da ja Unterschiedliche Bezeichnungen weil unterschiedliche Leute das unterschiedlich nennen )
auch erkennen würde ob alle Varianten eines if Aufrufs der and und or etc. enthält auch getestet wurden.

[TurboMagic]

Zitat von Stevie:

CodeCoverage ist leider noch enorm instabil und bei nur dem kleinsten Fehler in der map Datei (da werden manchmal Code Addressen als ausführbarer Code gelistet, die gar nicht stimmen, bzw in die auf gar keinen Fall ein Breakpoint darf) klatscht es gegen die Wand.
Besonders bei Generics (muss ich wohl wissen, hab bereits einige Stunden reingesteckt um einen vollständigen Report für die Spring Tests zu bekommen, der auch korrekt ist) fliegt es sehr oft auseinander.

Aber da ja jüngst irgendwie so ein kleiner Hype um das Projekt ausgebrochen ist, lehn ich mich zurück und warte, bis es jemand fixed.

Also ich werde CodeCoverage.exe sicher nicht fixen, da kenn' ich mich zu wenig aus.
Ich weiß auch gerade nicht, was dort derzeit als Issues alles gemeldet ist, d.h. ob diese Probleme die du gesehen hast dort bekannt sind.

Das bisschen Nutzung welches ich bisher hatte (im Rahmen der DEC) schien ok zu sein.
Aber zugegeben: DEC enthält auch kaum Generics und wenige annonyme methoden.

Grüße
TurboMagic