I have f# project with the following lines included
type PrimePair = {
p:int ;
q:int }
[<Theory>]
[<InlineData(1, false)>]
member t.``primePair`` (a : int) (expect : bool) =
// Act
// Assert
let primePair = {p=2;q=3}
Assert.Equal(primePair.p, 2)
Assert.Equal(primePair.q, 3)
()
Ncrunch is black-dotting the type PrimPair with No tests covering this line.
The xunit test exercises the type.
Any ideas ?
Remco NCrunch Developer
#7257
28 Apr 2015 23:46 UTC
Hi, thanks for sharing this.
This is an interesting problem.
The reason NCrunch considers the 'type PrimePair' line to be code is because the FSharp compiler generates a number of methods for this type behind the scenes, and binds these methods into the assembly's debugging data. What is particularly interesting about this is that not all autogenerated methods are actually being bound into the debug data - only the CompareTo and GetHashCode methods.
You'll notice that if you extend the test to call PrimePair.GetHashCode(), the generated line will be marked as covered by NCrunch.
NCrunch relies very heavily on the debug data (stored in .pdb files) to identify physical lines of code when it instruments assemblies. Basically, if code in the assembly has data associated with it in the PDB, it's considered to be eligible for tracking by NCrunch. In this case, we have code that is legitimately represented in the debug data but in a logical sense doesn't really exist (i.e. you haven't written a GetHashCode method).
I'm at a bit of a loss as to how this can be fixed within NCrunch itself. NCrunch is language independent - it does not differentiate between C#/VB.NET/F#, simply relying on these compilers behaving consistently in the IL they emit. Trying to devise ways to identify this generated code and screening it out is likely to be error prone and may introduce side-effects. In my belief, it doesn't really seem right that the F# compiler is binding the debug information in this way.. though it's possible they have a good reason for doing this.
If the black dot bothers you, I would suggest marking the line with a coverage suppression comment:
type PrimePair = { //ncrunch: no coverage
p:int; q:int }
This is an interesting problem.
The reason NCrunch considers the 'type PrimePair' line to be code is because the FSharp compiler generates a number of methods for this type behind the scenes, and binds these methods into the assembly's debugging data. What is particularly interesting about this is that not all autogenerated methods are actually being bound into the debug data - only the CompareTo and GetHashCode methods.
You'll notice that if you extend the test to call PrimePair.GetHashCode(), the generated line will be marked as covered by NCrunch.
NCrunch relies very heavily on the debug data (stored in .pdb files) to identify physical lines of code when it instruments assemblies. Basically, if code in the assembly has data associated with it in the PDB, it's considered to be eligible for tracking by NCrunch. In this case, we have code that is legitimately represented in the debug data but in a logical sense doesn't really exist (i.e. you haven't written a GetHashCode method).
I'm at a bit of a loss as to how this can be fixed within NCrunch itself. NCrunch is language independent - it does not differentiate between C#/VB.NET/F#, simply relying on these compilers behaving consistently in the IL they emit. Trying to devise ways to identify this generated code and screening it out is likely to be error prone and may introduce side-effects. In my belief, it doesn't really seem right that the F# compiler is binding the debug information in this way.. though it's possible they have a good reason for doing this.
If the black dot bothers you, I would suggest marking the line with a coverage suppression comment:
type PrimePair = { //ncrunch: no coverage
p:int; q:int }
Deleted post
#16984
22 Jan 2024 11:04 UTC
Deleted post
#17794
09 Dec 2024 10:06 UTC
Deleted post
#17853
16 Jan 2025 07:24 UTC
Deleted post
#17864
24 Jan 2025 15:03 UTC
Deleted post
#17885
08 Feb 2025 07:25 UTC
Deleted post
#17921
12 Feb 2025 13:45 UTC
Post a reply
Log in to reply.