Open Daenyth opened 3 years ago
I personally prefer the mixin style but didn't want scalacheck-effect to diverge from the syntax used by munit-scalacheck. If there was a mixin trait in munit-scalacheck that provided the various forAll
definitions, I'd have no problem adding a similar forAllF
mixin to this project.
If it was restricted to a scalacheck-effect-scalatest package, would that help?
I don't think so, as we'd still have the same disparity between forAll
and forAllF
. Given that ScalaTest doesn't support forAllF
at all, I think what you're really after is a forAll
mixin for vanilla Prop
values.
Note source compatibility is generally just an import away -- import org.scalacheck.Prop.forAll
i've been looking into how to use scalacheck in scalatest for properties that return an effect, i came across https://gist.github.com/mpilquist/7dd30a44ca2a7fe0cd494d9b04e4f661#file-eff-scala from yourself @mpilquist
is that not what we're after in this issue?
To help this be a better drop-in upgrade from scalatest-scalacheck, it would help to have mixins that provide
forAll
helpers in the style ofScalaCheckPropertyChecks