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

[freimatz]

Hallo,
damit es nicht so ein durcheinander hier gibt fange ich hier einen separaten Thread dazu an.

Ich gehe mal wieder ran und versuche nun ein Coverage.
Ich mache das jetzt mal etwas ausführlicher. Was genau hilfreich ist weis sich nicht. Ich schreib einfach mal meine Gedanken dazu. HTH.

Konkreter Anlass: ich habe in einer unit eine Methode ergänzt und möchte wissen ob für diese (und ggf. auch alle anderen Methoden) der unit test vollständig ist.
In meinen vorigen Versuchen hatte ich eine separate Workingcopy. Nun bin ich in meiner aktuellen. Dazu ziehe ich dort DelphiCodeCoverageWizard.dproj in meine Projektgruppe.
Noch ein pull, bin auf Revision: b8b4f992 Date: 20.11.2022 16:05:02
Dazu hole ich mir auch das Projekt von DelphiCodeCoverage und compiliere das.
Zurück in Wizard, F9, es startet. :thumb:
1. Keine Icons mehr, ist mir gerade nicht wichtig. :arrow:
2. Map file kommt nicht von alleine, also selber eintragen ... ach ne ist ja noch nicht da -> featurerequest: bei der Angabe der Dateien eine Angabe ob die aktull ausgewählte auch vorhanden ist. :!:
3. Command line parameter: das -ife lasse ich mal weg, das macht ja nun der Wizard nehm ich an. :arrow:
4. Source, ich habe hunderte Dateien, etwas mühsam da auszuwählen. Aktuell egal, mich interessiert nur eine unit. Sonst habe ich auch schon mal die dccp editiert.
5. HTML und "Save log ..." an
6. Ah "Save project & ..." ist enabled :thumb:
7. "Save project as ..."" :arrow:

Code:

---------------------------
Error
---------------------------
Failed to create path: 
Reason: Unable to create directory
[]
---------------------------
OK   
---------------------------

Wäre schön er würde auch sagen was für ein directory ;-) (ich weiss was es ist und korriere das)
8. Neuer Versuch. Coverage startet - es gibt ein Ergebnis. Nur eine Datei. Covered 3, Not Covered 1660 :gruebel:
9. Ah falsche Datei, Parameter "-ife" fehlt doch noch, ich füge ihn manuell hinzu, neuer Versuch ...
10. Wieso habe ich nach einem Lauf nur "Home" und zwei weitere disabled Buttons? Muss jedesmal das Projekt wieder laden
11. Nun die richtige Datei. Allerdings ist das Ergebnis schlecht. :oops: Mein Fehler es waren zu wenige Tests ausgewählt - neuer Versuch
12. Ergebnis sieht nun viel besser aus. Suche im Ergebnis meine neue Methode - alles grün. Auch sonst ist die unit mit 97.3% recht gut. Woran es noch fehlt sieht man sehr gut im Report. :thumb::-D8-):dancer2:

Als nächstes wären weiter units dran und vielleicht auch mal gleich ganze Module. Ausserdem bei uns eine Diskussionen wo man die Scripte speichert und ob die map immer an sein sollten. Ggf. melde ich mich dann wieder.

[freimatz]

Doch schon gleich der nächste Versuch. Dieser hat jedoch keinen Erfolg. :pale:
Es geht um das Modul wo ich den meisten Code gemacht habe. Im Gegensatz zum vorigen Versuch enthält dieser auch Klassen und Generics.
Der Wizard scheint seine Sache noch richtig zu machen. CodeCoverage.exe startet. Nach Prozess-Explorer wird auch das Testprojekt gestartet. Dann hängt CodeCoverage.exe lange Zeit mit ca. 8% CPU. Das Testprojekt zeigt sich jedoch überhaupt nicht. Nach langer Zeit ist die Sache zu Ende. Der Report ist da, jedoch ist die Coverage bei 0.
Bin nun im Debugger und bin nun hier.

Delphi-Quellcode:

function TDebugger.StartProcessToDebug: Boolean;
var
  StartInfo: TStartupInfo;
  ProcInfo: TProcessInformation;
  Parameters: string;
  WorkingDir: PChar;
begin
  Parameters := FCoverageConfiguration.ApplicationParameters;
  FLogManager.Log(
    'Trying to start ' + FCoverageConfiguration.ExeFileName +
    ' with the Parameters :' + Parameters);

  FillChar(StartInfo, SizeOf(TStartupInfo), #0);
  FillChar(ProcInfo, SizeOf(TProcessInformation), #0);
  StartInfo.cb := SizeOf(TStartupInfo);

  StartInfo.dwFlags := STARTF_USESTDHANDLES;
  StartInfo.hStdInput := GetStdHandle(STD_INPUT_HANDLE);
  StartInfo.hStdOutput := GetStdHandle(STD_OUTPUT_HANDLE);
  StartInfo.hStdError := GetStdHandle(STD_ERROR_HANDLE);

  WorkingDir := nil;
  if FCoverageConfiguration.UseTestExePathAsWorkingDir then
  begin
    WorkingDir := PChar(ExtractFilePath(FCoverageConfiguration.ExeFileName));
  end;

  Parameters := '"' + FCoverageConfiguration.ExeFileName + '" ' + Parameters;
  Result := CreateProcess(
    nil,
    PChar(Parameters),
    nil,
    nil,
    True,
    CREATE_NEW_PROCESS_GROUP + NORMAL_PRIORITY_CLASS + DEBUG_PROCESS,
    nil,
    WorkingDir,
    StartInfo,
    ProcInfo
  );

  FProcessID := ProcInfo.dwProcessId;
end;

Ich meine danach sollte das Testprojekt sichtbar sein. Was könnte da schief gehen?
Einige Werte:

Code:

Watch Name   Value
Parameters   '"J:\Bla\sysWin32\TestDomainBlub.exe" '
WorkingDir   nil {#0}
StartInfo   (68, nil {#0}, nil {#0}, nil {#0}, 0, 0, 0, 0, 0, 0, 0, 256, 0, 0, nil, 156, 160, 164)
ProcInfo   (508, 504, 15152, 11800)

WorkingDir zu setzen hat nichts gebracht.

Nachtrag: Habe in TDebugger.ProcessDebugEvents den Timeout erhöht. Er kommt nun nicht mehr bei "FLogManager.Log('Wait For Debug Event timed-out');" vorbei, hilft aber insgesamt auch nicht.

[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. 8-)

[freimatz]

Und ich dachte, da ist ein Hype ausgebrochen, das muss ich ausnutzen :twisted:
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. :pale:

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1515266)

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

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:

Zitat von Uwe Raabe (Beitrag 1515269)

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:

Zitat von Stevie (Beitrag 1515315)

Zitat:

Zitat von Uwe Raabe (Beitrag 1515269)

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. :roll: 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.

[freimatz]

Hallo zusammen,
ich gehe euch allen recht.
Wegen "professionell": würde mein Aussage gerne zurückziehen. Habe wikipedia gelesen und der Begriff ist zu wenig eindeutig.

Build-Prozess:
a) wir hatten das mal mit Jenkins, Sonar-Cube und AQTime. Hat leider nicht funktioniert.
b) ich bin weit davon weg davon zu träumen dass das mal geht. Ich wäre schon froh, dass wenn das lokal bei mir geht für das was ich mache.

Im aktuellen Fall habe ich gut 700 Zeilen Code-Änderungen in vielen Klassen und etlichen unit. Vieles ist nicht neu sondern umgebaut. Bin mir nicht sicher wo es dazu unit-tests gibt. Eine händische Kontrolle ergab, dass die Abdeckung extrem schlecht ist.
Uwe, Dein DelphiCodeCoveragePlugin habe ich wieder mal angeschaut und ausprobiert. Es funktioniert in dem beigefügten Testprojekt, nicht jedoch in dem Code den ich machte. Ich vermute mal es liegt daran, dass der Test-Code in einem anderen Modul ist wie der Produktivcode. Leider kann ich das nicht ohne weiteres ändern. (Bei Methoden im selben Projekt gehts. Es gab einige false negatives beim "end" von anonymen Methoden.)

"Codebase von Millionen von Zeilen und abertausenden von Unit- und Integrationstests" - das haben wir definitiv; dazu kommen noch automatisch UI-Tests.

Und Ja, ich weiss, dass Zeilenweise Code Coverage ist nicht ausreichend ist. Aber ich wäre froh wenigstens das mal zu haben.