SteveGilham
commented
9 months ago Coverage numbers like this are indeed orders of magnitude higher than I've observed in real life testing in my corporate career; hence no limiter has been built in, as that would incur a cost on every visit, for something expected never to happen.
Setting the prepare options SingleVisit property to true will paper over the problem by replacing visit counts by an effective boolean - 1 or 0 for visited or not.
Inspecting the quoted fragment of the coverage report and the matching source, the values are consistent with 2391726432 times when a collection is being inspected, of which only 3.6% have more than one member. The number of non-trivial collections in get_Count approximately match up with the number of calls to the [] indexer (aka get_Item) that fetch items at non-negative offsets, of which 2.6% are at indexes above 0.
This looks to me like the coverage tool is, as a side-effect, pointing out a hot-spot in the library as implemented. The methods within the NonEmptyCollection type are rather fond of invoking the Count property rather than caching and managing it; this including the enumerator type. This looks like it is ripe for cases where innocent looking application code makes a call that does more repetitive work than would be apparent on the surface.
denis-gvardionov
When using AltCover version 8.6.68 for analyzing the code coverage in the project, AltCover generates a coverage report in XML format, where some integer numbers exceed the
System.Int32.MaxValueupper limit (2147483647). And because of this the subsequent procedure cannot import such a report, because cannot parse the too big integer value.The error message is the next:
And the next:
Here is a part of report, generated by the AltCover, where such invalid value is located:
After subsequent investigations we’ve found that AltCover generates such out-of-range-integers not for the random code, but for the two specific methods, located within two classes. We made a workaround by excluding these two classes from the analysis by using a “
FileFilter” property from the “coverage prepare options” class, which implements the “AltCover.Cake.PrepareOptions”. After such exclusion all is working well.We tried different ways to figure out why the AltCover generates out-of-range-integers especially for specific code pieces, but without luck. There is a very usual code there, nothing special.
Our project is a closed-source commercial library, so we cannot share the whole of its code base. But we can share these two files, where problematic code is located. We also share the reports generated by AltCover.
List of attached files:
7z archive with these 4 files is located here: https://drive.google.com/file/d/18A9C1awXcrXWztWFLG7qMVLygA3qEx7X/view?usp=sharing (I cannot attach files directly because they are too big)