-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gen.suchThat not respected by shrinking after Gen.map #129
Comments
This is a known issue. With the current design it is not possible retain the |
Hmm, I guess this is the same issue then: Using scalacheck-1.12.2 with scalatest-2.2.5 and scala-2.11.6 executing "Test scalacheck" in {
val gen = for {
n <- Gen.choose(1, 3)
list <- Gen.listOfN(n, Gen.choose(0, 9))
} yield list
forAll(gen) { list =>
list should not be (empty)
if (list.sum < 18) throw new IllegalArgumentException("ups")
}
} results in
This problem is also mentioned on http://stackoverflow.com/questions/20037900/scalacheck-wont-properly-report-the-failing-case although the bug mentioned there was closed a while ago. Here is another example where "Test scalacheck" in {
val gen = for {
n <- Gen.choose(1, 5)
list <- Gen.listOfN(n, Gen.choose(0, 5))
} yield(n, list)
forAll(gen) { case (n, list) =>
if (list.sum > 18) throw new RuntimeException()
n should not be (0)
}
} results in
|
Yeah, I keep hitting this issue as well, very annoying. |
Scalacheck was right to tell me something was wrong - but generating zero-display-width characters in Gen.alphaStr was definitely UNHELPFUL. typelevel/scalacheck#129 https://twitter.com/rtyley/status/1016244507761889280
Apologies for just repeating the same question slightly differently but isn't the fundamental problem that
FWIW The Haskell version of Is using the implicit Shrink intentional, or something that should potentially be removed given people keep hitting this issue (I've met others offline with the same problem)? Having a separate gen and shrink mechanism is one of the (unfortunate) design flaws in the original QuickCheck. Not to hijack this issue for my own agenda but if people are interested it's something that has been "fixed" in a new-ish library Hedgehog which combines Gen/Shrink (Admission: I'm the current maintainer of the Scala Hedgehog port, but a long time QuickCheck/ScalaCheck user and admirer). |
Shrinking is only safe when used with Arbitrary. Generators can have a smaller range than the global shrinking, which results in invalid shrunken values. This fixes issues like typelevel#129.
As suggested by @ashawley (in gitter) here is a link to (my) scala implementation of the hedgehog concept/library in Scala. https://github.com/hedgehogqa/scala-hedgehog Sorry again for hijacking this thread to spruik a replacement/alternative to ScalaCheck. As I said earlier, I've been a long-time user and fan of this library! |
Indeed, shrinking that doesn't respect generators is confusing. It could probably be improved with documentation. This issue isn't covered in the ScalaCheck book, nor the online User Guide. There is a proposal in #440 to disable shrinking by default in the next major release, 1.15.0. Technically, such a change could avoid breaking existing passing tests and preserve binary compatibility, but a user who upgrades to 1.15.0 and found out that shrinking was dismantled would be a pretty surprising change. It's a signicant enough change that is should probably ship in a 2.0 release. |
My team has a library which contains a bunch of predefined generators. Here's a simple one:
Unfortunately when I go to use it in practice, this doesn't get respected at all. (We use specs2 along with ScalaCheck, so bear with me.)
This results in some output like
If I use
forAllNoShrink
, or if I writegenNonEmptyAlphaStr.suchThat(_.size > 0)
, then there are no problems and I get single-letter strings. If I useGen.nonEmptyListOf(Gen.alphaChar)
(in other words, I don't map on it,) then I also have no problems. It's only after I.map(_.mkString)
that it will shrink to the empty string.tl;dr
Gen.map
invalidatessuchThat
.The text was updated successfully, but these errors were encountered: