leanovate / gopter

GOlang Property TestER
MIT License
599 stars 40 forks source link

Getting values outside of range when using gen.IntRange (probably during shrink) #81

Open rciorba opened 3 years ago

rciorba commented 3 years ago

Hello! Thanks for this great library and apologies in advance if this is me just missunderstanding it (go newbie).

I've got a stateful system, a bitarray and the state is a []bool. I'm trying to assert that the bitarray is equivalent to the state ([]bool).

I'm using 2 gen.IntRange:

Despite using IntRange to stay within the bounds of he SUT and state, I eventually see illegal values (I suspect during the shrink phase, as they only appear after the post condition fails), which causes the test to panic.

Is this intended behaviour for the gen.IntRange (to shrink outside the range)?

Another interesting detail: if I remove the IntRange from the initial state and only keep it in the command, the Index values for the command stay within range and I never see the panic.

See an example here: https://play.golang.org/p/xplrfKS_Nvm

Thanks!

untoldwind commented 3 years ago

No, the IntRange should not shrink outside the given range. Can you give me a short sniplet about the different ways you construct the initial state, i.e. the working variant and the one that panics

rciorba commented 3 years ago

Hello, and thanks for following up!

I've simplified my test to try to reduce it to a condensed form. I think the a second IntRange for the InitialState was a distraction as I can reproduce the issue with a single IntRange for the command and a constant for the InitalState.

Here's the simplified example: https://gist.github.com/rciorba/79e17881b1739afe2ff504b7edbcfc73/revisions?diff=unified The initial revision is the working test (using a OneConstOf). The second revision uses the IntRange and starts to produce values outside the range once the post-condition is violated.

untoldwind commented 3 years ago

Thanks for the detailed example. There is indeed something of with command shrinker, unluckily it is not so easy to fix.

So here the TLDR workaround: Make use of the command.PreCondition like this:

func (s setCommand) PreCondition(state commands.State) bool {
    return s.Index >= 6 && s.Index < state.(int)
}

Longer explanation: The shrinker relies on the Sieve in the gen.Result . Unluckily the commands package still uses the gen.FlatMap to create a generator for a sequence of commands from a single command generator (actually it is a sequence of FlatMaps). The gen.FlatMap has the known drawback of removing the Sieve because there is no easy way to (flat)map that. A better variant would be to use gen.DeriveGen at this place, which is unluckily not straight forward, so I'm currently playing around with several other potential solutions.

untoldwind commented 3 years ago

Just after writing the comment above I came up with a new solution that required only a small change.

The current version in the master branch should fix the problem.

rciorba commented 3 years ago

@untoldwind Thanks for the fix! ~I tried it and my test no longer crashes.~

rciorba commented 3 years ago

Sorry, seems I tried it with the "intentional bug" commented out and that never triggers the shrink stage.

I can still reproduce the issue, using github.com/leanovate/gopter v0.2.10-0.20210503084252-f350002bbbe3

untoldwind commented 3 years ago

I tested with this: https://gist.github.com/untoldwind/f78910c522f6efb81ac140891016a5da

According to the output the "Index" stays within its bounds during shrinking. Is this maybe a different issue?