Doctest from the scaladocumentation of the source code of my project. And it makes the test to finish in failure... is there any way to disable this feature? I'm using "org.scalatestplus" %% "scalacheck-1-14" % "3.1.1.1"
How do I use a forAll in my regular ScalaTest specification, without going "full ScalaCheck" (and by that I mean I do not want to extend Properties(...) and wrap my forAlls in a property)?
I can see there's forall(...).check but that doesn't fail the test, and the documentation also says it's only a convenience method.
I've read the user guide but couldn't see anything that answers this (I could have missed something...)
scalatestplus-scalacheck and extend with Checkers in your spec, then you can use check(forall(...)) to run your properties :)
BaseTask implementation. would it be fair to say that the Seq of properties should not be modified once it's assigned to props here? https://github.com/typelevel/scalacheck/blob/123cba0b21d8ecb8d61e84549ddcbf61890e008b/src/main/scala/org/scalacheck/ScalaCheckFramework.scala#L63-L66
Seq of props once Properties#properties is called?
genMobilePhone and a genHomePhone andI want to make a genPhoneListWithAtLeastOneMobile
Gen.nonEmptyList(Gen.oneOf(genMobilePhone, genHomePhone)) but that wont guarantee I have at least one mobile...
final case class VisitActivityQuestionAssignmentStudyEnvironment(
id: UUID,
description: String,
orderIndex: OrderIndex,
methodAssignments: Seq[MethodAssignment]
) {
require(description.trim.nonEmpty, "Description parameter should not be empty")
}
sizeRange parameter (I'm using scalatest's ScalaCheckPropertyChecks) but that doesn't seem to have an effect.
.sample the option can provide it. Let me know if this kind of usage need an issue ?val pw = new PrintWriter(f)
for {
sample <- Gen.choose(5000, 100000).sample
_ <- 0 until sample
t <- Gen.choose(-500f, 500f).sample
} {
pw.write(s"$t\n")
}
pw.close()
I have a question about the default Shrink[Int] instance.
From what I can see, it "simply" halves its input it reaches 0. This obviously works, but isn't very precise. Let's say, for example, that you have the following property:
val propTest = forAll { i: Int =>
i < 156
}If you get an input of, say, 482, it'll get halved to 241, then get stuck there - it has no way of getting back "up" from (241 / 2) to 156.
An alternative implementation would be to halve the input, but then explore the larger part of the halved space:
implicit val intShrink: Shrink[Int] = {
def halves(inf: Int, sup: Int): Stream[Int] = {
if(math.abs(sup - inf) <= 1) Stream.empty
else {
val mid = inf + (sup - inf) / 2
mid #:: halves(mid, sup)
}
}
Shrink(i => halves(0, i))
}I've ran some tests and this seems to consistently find the most precise value possible.
Was there any reason it wasn't implemented that way? For example, "hoping" for a value closer to 0 and avoiding getting stuck in a local optimum?
@ashawley yeah I've actually pushed the experience further and it's not actually a good idea. Binary search works because you keep a running context - [a, b]. With shrinking, you do have that context while looking for the next failing test case, but you lose it as soon as you find that test case.
That is, you can be looking for your local minimum in [100, 150], and you'll end up searching in [0, 125].
You end up spending far more time looking at values you've already explored, and I'm not at all convinced it's safe - there *must be some infinite loop scenario
def noShrink[T]: Shrink[T] = Shrink(_ => Stream.empty)
Stream, whats the recommendation here?
withLazyList in #627.
3 replies