Fuzz.int generates values outside of Int32 range

[MartinSStewart]

The documentation for Fuzz.int states that it generates any 32 bit signed integer value but I've found that it can generate the value 2147483648 which is one greater than largest maximum Int32 value.

elm-test version: 1.2.0
OS: Windows 10

[mgold]

The fuzzer is capable of generating values from -2^32 + 1 to 2^32 - 1. Perhaps it should generate any value representable in a signed or unsigned int32, so -2^31 to 2^32-1. Or we could add Fuzz.unsignedInt and Fuzz.signedInt. Or use Fuzz.int to be signed. Or some other variation. Any thoughts?

[MartinSStewart]

I think adding Fuzz.unsignedInt and Fuzz.signedInt (maybe name it Fuzz.unsignedInt32 and Fuzz.signedInt32?) would be the best choice. I'm trying to fuzz test elm/bytes encoders and decoders. Having those functions makes it clear to use them over Fuzz.int in addition to preserving backwards compatibility.

I'm not sure if going in this direction means also adding a Fuzz.unsignedInt8, Fuzz.unsignedInt16, etc. or if that will add too much bloat the library.

[rtfeldman]

A couple thoughts:

1. This seems like something that is useful in conjunction with elm/bytes but not otherwise. Maybe this means functions like that should go in a Fuzz.Bytes module, or even a separate elm-test-bytes package.
2. Since JS supports "52-bit" integers, should the current implementation generate even bigger and smaller numbers? (This would probably greatly increase the number of fuzz tests that overflow. Is that a good thing or a bad thing?)

[MartinSStewart]

1. I prefer adding a Fuzz.Bytes module. To me it doesn't seem like there are enough new functions to justify a new package. Additionally, I think, whichever way is chosen, the documentation for Fuzz.int should be changed to avoid misleading people into thinking it generates values exactly within the signed int 32 range. It's possible for this fuzzer to generate any 32-bit integer, but it favors numbers between -50 and 50 and especially zero. could instead be It's possible for this fuzzer to generate any integer between -2^32 + 1 and 2^32 - 1, but it favors numbers between -50 and 50 and especially zero. Note that this is larger than what is representable in a 32 bit int. Use Fuzz.Bytes.signedInt32 or Fuzz.Bytes.unsignedInt32 if you need that.

2. I think it would be better for Fuzz.int to represent the full JS int range. I want it to make sure that functions I write behave correctly even with unusually large/small values. Also this is actually what I thought it did before reading the documentation for it.

[rtfeldman]

I think it would be better for Fuzz.int to represent the full JS int range. I want it to make sure that functions I write behave correctly even with unusually large/small values. Also this is actually what I thought it did before reading the documentation for it.

One consequence of this would be that any function you write which uses addition, subtraction, or multiplication on a Fuzz.int value will be more or less guaranteed to overflow or underflow.

Is that desirable? It sounds like it would make Fuzz.int something nobody could usefully use in practice.

[MartinSStewart]

Hmm, good point. Without trying to write a bunch of tests with it I'm not sure if I would find it a hassle or if it would uncover actual bugs. Maybe we need a Fuzz.pragmaticInt and Fuzz.theEntireThingInt (but with better names). Or maybe that's also too much bloat and Fuzz.int works the way it is now.

[mgold]

Regarding Fuzz. Bytes: Try writing fuzzers that do what you need them to do to test your Bytes-using code. Then move them to their own file, a Fuzz.Bytes within your project's testing directory. Use them for awhile and see if you have the right set of functions and if they shrink values in reasonable ways. Then consider releasing a third-party package, elm-test-bytes or similar. And if that third-party package becomes massively popular, we can consider adding them to the main library.