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
Hi, I want to include some properties into ordinary AnyFunSuite, for example
MyAwesomeTest extends AnyFunSuite {
test("ordinary test") {
assert(true)
}
test("scalacheck test" {
val prop = forAll { b: Boolean =>
b
}
prop.check()
}
}How can I launch property check in that scenario? I want to have a red failed test instead of
! Falsified after 0 passed tests.
> ARG_0: 0
> ARG_0_ORIGINAL: 71I haven't found the answer in https://github.com/typelevel/scalacheck/blob/master/doc/UserGuide.md
test("scalacheck test") {
forAll { b: Boolean =>
b
}
}
Auto-application to `()` is deprecated. Supply the empty argument list `()` explicitly to invoke method dispatch,
or remove the empty argument list from its definition (Java-defined methods are exempt).
In Scala 3, an unapplied method like this will be eta-expanded into a function.
forAll {}