Repository navigation
Code Coverage ignores most units #19
Description
I am working on a Delphi project with 230 units in it and tried running Delphi Code Coverage on it using the Delphi Code Coverage Wizard, but in the end result, only 19 of the 230 units were included, despite Delphi Code Coverage printing "Will track coverage for:" for each of the 230 units (using verbose output).
Also, I know that the code is roughly 80.000 lines long, but Delphi Code Coverage only recognized about 6.000 of those.
Here's the strings that I ran (both created the same result:
CodeCoverage -e PBeratungsapp_Tests.exe -m PBeratungsapp_Tests.map -uf test_results/script/dcov_units.lst -spf test_results/script/dcov_paths.lst -od test_results -lt -xml -html -vCodeCoverage -e PBeratungsapp_Tests.exe -m PBeratungsapp_Tests.map -uf test_results/script/dcov_units.lst -spf test_results/script/dcov_paths.lst -od test_results -lt -xml -html -v -ife
Here's the files that were generated by the wizard (converted to .txt so that GitHub lets me upload them):
dcov_paths.lst.txt
dcov_units.lst.txt
Is this a configuration issue on my end? Is there something I can do to get Delphi Code Coverage to cover my entire code? Or is this an issue with Delphi Code Coverage?
Activity
Laurensvanrun commentedon Mar 17, 2022
I doubt whether it is an issue with the tool itself, I think it is a configuration issue. However, I would like to be able to reproduce it and see where it fails. Is it possible that you share a private repository with me so I can have a look at it?
KiraResari commentedon Mar 18, 2022
Sorry, I'm afraid I'm not a liberty to share this project. However, maybe you can tell me what to do in order to get some relevant data on the problem. Unfortunately, neither the verbose output was of any help to me (it only displayed the list of modules and files, followed by the result after a 5 minute wait), nor was a log file produced despite me specifying -lt.
freimatz commentedon Nov 18, 2022
Same here. I debugged some ...
I found all filenames contining at least one dot are corrupted.
This happens at line "UnitLine := PathExtractFileNameNoExt(UnitLine);"
In the readme i did not found the information if the files have to contain extension or path
In addition parameter '-ife' doesn't work cause TCoverageConfiguration.ParseSwitch is called after this.
MHumm commentedon Nov 19, 2022
Ok, we need to investigate and fix these issues to move forward. I'm not familiar with that codebase yet though. But if somebody is not proficient with GitHub creating a pull request for the necessary changes I might do them and create the pull request.
ekot1 commentedon Nov 19, 2022
I'll have some time to check it today
ekot1 commentedon Nov 20, 2022
Can you try to put -ife switch before -uf, because if it affects parsing of include file.
freimatz commentedon Nov 21, 2022
Thanks a lot. With this option in front the file handling after a short try it seems to be correct. However in my opinion the order of the parameters should not matter.
MHumm commentedon Nov 21, 2022
Have you checked the demo showing the issue I linked to here:
#33
The link is valid for a little less than 30 days now.
MHumm commentedon Nov 21, 2022
I add the -ife switch just before -uf now in my wizard, as I didn't add it before. Is this a good idea to add this generally?
ekot1 commentedon Nov 22, 2022
Yes, because it affects -uf processing.
MHumm commentedon Dec 1, 2022
@KiraResari
Did you try this -ife switch in your test meanwhile? Does it help?
KiraResari commentedon Dec 5, 2022
I've got it on my to-do list. I'll check it out when I get around to it. I'm reasonably sure that I didn't, so I am curious to see what result it will produce.
KiraResari commentedon Dec 9, 2022
Slight update: I tried getting it to run again today, and found that the new version of DCC was blocked by F Secure Deep Guard again (just like the last version), which heuristically classified it as Malware. This also happened the last time I tried this and I had to wait, like, a week for them to unblock it. Any idea why this happens and if there's anything that can be done about this?
ekot1 commentedon Dec 9, 2022
I don't think there is anything we can do about it, since by its nature DCC does set breakpoints in .exes, read other process memory, etc. all actions that can be deemed suspicious, although I did not have it blocked by other AV products.
MHumm commentedon Dec 9, 2022
Some AV products allow to exclude certain files or directories. That would help, if possible for FSecure.
KiraResari commentedon Dec 12, 2022
Yup, I expected as much. So this is just to keep you posted that now I'll have to wait until they unlock it, which might at worst case take until the new year =>,<=
Anyway, FYI, here's the complete error message that F-Secure threw out. Not that I think it will help much, but maybe it's something to laugh/cry about in the meantime:
MHumm commentedon Dec 21, 2022
If the CodeCoverage.exe would be digitally signed it might not happen, as F-Secure might be able to trace the certificate and then accept that it's a legal/proper app. Not sure if that works and yes, a certificate costs money.