Print percent of *tests* where element of a model coverage is involved #95
Labels
code: enhancement
New feature or improvement
part: model coverage
Related to model coverage of generators
status: discussion
Suggested or reported thing is not obvious to be good enough
status: feature request
Request for new functionality or improvement
status: good first issue
Good for newcomers
Currently, after the #94, count of presence in a model coverage is printed along with coverage status.
Now it looks like this (takes from test here):
There were 100 tests generated,
Y
was used in each test once, thus the whole count of usages of the typeY
is 100% for the tests, where individual actually generated constructors have 41% and 59% respectively.But when type is recursive, or just is used several times, one can get percentage >100% (taken from another test here):
Actually, type
X
is present in 59% of the tests, along with theY3
constructor, but each time it is present twice. If we were printing this with a percentage,118%
near to theX
type would be a misleading number, where "present in 59% of tests" could be feasible one.So, it is suggested to add percentage of presence in the tests, but we must be accurate and (unlike the current times coverage) to not to count each model coverage element several times in a single test.
The current design does not support this directly, we don't store this type of data. There are at least two possible solutions to this:
change the order of
ModelCoverage
collection so that each test usesregisterCoverage
independently, and thus is can be changed to calculate percentage of mentions of types and constructors per test; I don't like this solution because of potential high count of calls to relatively expensiveregisterCoverage
function;to have two separate
Semigroup
s implemented for theModelCoverage
type: one is for use with theWriter
inside appropriateunGen
which does not accumulate the usage-per-test metric, and is not exported outside the module; and the other which does accumulate usage-per-test metric and is exported outside; the latter one should be declared in the bottom of the module to not be used accidentally in theWriter
context.The text was updated successfully, but these errors were encountered: