Open stevana opened 5 years ago
This is the intended behaviour of coverTable
. The requirement in the latter case is that B
makes up 10% of the values in table C
. If C
never appears that's not necessarily violated. It wouldn't necessarily be amiss to have a warning about never seeing C
in the test, however...
It's a bit of a degenerate case, because B
makes up both 100% and 0% of the values in table C
:) I agree that it would be good to have a warning.
@MaximilianAlgehed: I also recently misunderstood the behaviour of coverTable
, and I think so did John, and now you... so, something is confusing about it :) Do we need a better name, or better documentation?
I would be all for changing the name (and eventually deprecating the old name etc. etc.). But that's not enough, we do also need to make the documentation more explicit about the behvaiour I think.
The question is what to change the name to. coverTableElements
, coverTableDistribution
, coverInTable
? None of them really hint at the specific pitfall here, that the coverage is relative to only the table and not the tests themselves.
I've added a comment about this on master
to improve clarity
I'm reopening this as a request to have a warning when this happens. Feel free to close it again if you disagree :)
The simplest(?) solution might be to also print the empty tables:
> quickCheck $ coverTable "C" [("B", 10)] $ tabulate "A" ["A"] ()
+++ OK, passed 1 test.
A (1 in total):
100% A
C (0 in total)
Ooh, I like that!
When used as intended,
coverTable
gives a coverage warning:If one messes up and accidentally uses the wrong key, say "C" instead of "A", when calling
coverTable
it silently succeeds:It would be nice to have a warning in this case?
(In my actual use case I abuse the keys of
tabulate
to be from-states and the values to be to-states in a finite state automata.)