-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pipelines are seen as classes in cobertura report #177
Comments
Decompiling the assembly
and in fact represents the function object being passed to the The interesting thing in this example is that the function object representing the predicate on line 22 of the same code is still (using the 7.0.102 SDK to build) named according to the older convention as I have not bothered to delve into the guts of the compiler to see the whys and wherefores of the change. |
Thank you for your quick response and for the explaination. It indeed makes sense that if the decompilation shows a class, that a coverage tool would not be able to recognize that it actually is not a class. However that leaves me wondering why OpenCover does succeed in not marking it as a class. Is this an additional feature, that might come to AltCover as well in the future? |
I performed the following experiment to see what OpenCover is doing. 1 - create new F# console project (VS 17.4.4)
5 - build Loading the results.xml as an XML document in powershell via containing the same By way of comparison, the AltCover emulation of OpenCover generates the following manifest omitting the generated types that contain no methods. From what you are saying, though, I get the impression that emulating OpenCover's warts-and-all reporting style is not actually what you want. In that case, the coverlet emulation (a style that collapses those implementation detail types like |
Thank you for the extensive response. Unfortunately I haven't had time to fully reproduce and investigate it. However, I have ran some quick tests with /p:AltCoverReportFormat=Json and it indeed seems to do more what we want. I will experiment with it more in the coming weeks, but for now it looks like what I want! Thank you. |
Closing as the change in report format seems to have alleviated the original concerns. |
Hello Steve,
First of all, thank you for creating and maintaining AltCover, it is certainly appreciated!
On our buildserver I would like to make the switch from OpenCover to AltCover, however I ran into a problem. I am testing a solution with multiple projects on a jenkins buildserver, we would like to generate a Cobertura test report that can easily be published through Jenkins. However, in the coberturea report, in some cases pipelines are seen as different classes, which would generate an incorrect report.
Because our main project contains some IP that I may not share, I have created a simple demo project to demonstrate my problem, it can be found at:
https://github.com/MatthijsPrent/PipesAsClassesBug
This solution contains a very simple library called "PipesAsClassesBug" and a corresponding test project. The tests inside of the project are not very well implemented, but that is also not the purpose of this example solution, they should be sufficient for this example.
The repository also contains a test.bat file. This file contains the command that I use to run AltCover, and a sed command that I use before publishing the data on the buildserver, to remove absolute paths.
After running this bat, the output file can be found ad PipesAsClassesBug/PipesAsClassesBug.Test/AltCoverCobertura.xml. For example at line 168 the class "PipesAsClassesBug.SomeMethods/Pipe #1 stage #1 at line 13@13" is documented. However, this is not a class, but simply a F# pipe. Therefore, I would expect it not to be reported as a class.
I would like to ask you to look at my issue and provide me with some advice on how I can get the reporting correct. I hope that my example and explaination is clear, if it is not, please don't hesitate to ask me any questions. Thanks in advance for your reaction.
Kind Regards,
Matthijs Prent
The text was updated successfully, but these errors were encountered: