scalacheck
scalacheck copied to clipboard
typelevel
Generators library
It would be great if there was a library of reusable Generators / Arbitrary instances.
Over time we have noticed a certain set of generators that are project-independent and come in handy in when reused in various software projects. Just to give an idea what these include:
- collections: short lists (pot. empty / non-empty), small sets (pot. empty / non-empty), (small) maps (pot. empty / non-empty), lists of distinct elements
- numeric: positive / negative ints / longs / BigIntegers
- date / datetime / locales
- strings: no control chars, alpha (numeric) chars
- file system: file paths (relative + absolute)
- networking: HTTP / FTP / ... URIs / URLs (with / without credentials, ...)
I wonder if there's any interest in adding these to scalacheck (probably as a separate artifact, e.g. scalacheck-generators)? I could contribute such an initial set of generators.
According to #351, the opinion is to have other libraries provide more generators. Some of these already exist, which see:
https://index.scala-lang.org/search?q=scalacheck
Thanks @ashawley for the input. I've scanned the list of libraries providing generators you've linked and found quite some libraries. For myself and for everyone to read here, here's the list:
Macro-based generator generation
- scalacheck-shapeless providing generation of arbitrary case classes and ADTs via shapeless
- scalacheck-generators providing generation of arbitrary case classes and ADTs
- scalacheck-magnolia providing generation of arbitrary case classes and ADTs via Mangolia (seems to be gone from GH)
- random-data-generator providing generation of arbitrary case classes and ADTs via shapeless
- random-data-generator-magnolia providing generation of arbitrary case classes and ADTs via Magnolia
Generators for JDK stdlib types
- scalacheck-toobox providing datetime generators and some combinators
- datetime-generator
- scalacheck-ops providing a number of additional operators + generators for sets, size-bounded strings, enums, bitsets and binary
- scalacheck-money generators for money types (JSR 354 /
javax.money)
Generators for library types
- ratatool providing generators for Avro, Protobuf and BigQuery
Other generators
- scalacheck-schema generating generators from JSON schema (AFAIU)
As browsing the ScalaDex search result took some time, maybe this list can helps other looking for libs available. Or maybe it could be used as a starting point for linking libs on the website?
While that is already a great collection of generators (or generator generators), I'd like to add a different viewpoint to the statement
the opinion is to have other libraries provide more generators
and to @rickynils statement
Keep the current ScalaCheck lib slim (or make it even slimmer) and dependency-less. Encourage utility libraries for specialized functionality/combinators/generators etc. This does not imply that the ScalaCheck core should stop evolve/improve.
I think at the current state the "ecosystem of ScalaCheck generators" is somewhat fragmented. A first-time ScalaCheck / PBT user will only find a relatively basic (even though great) set of building blocks for composing custom domain-specific generators within ScalaCheck itself. Some thoughts related to that:
- I have experience introducing ScalaCheck both within projects and at my local Meetup group. I've seen a certain scepticism about how much effort one needs to put in writing generators to actually use ScalaCheck in a project. This contributes to increase the mental barrier for trying out PBT in the first place.
- ATM there's no comprehensive library with generators for everyday use cases. Having such a library would lower the entrance barrier and efforts related to adopting PBT / ScalaCheck.
- Writing generators for stdlib types should ideally only be done "once" as an OSS lib, one should avoid to (re)build/duplicate them for every project. Generators must be stable and well-designed as in the worst/best case the stability and correctness of your software is dependent on it. A good generator is often not trivial to write, therefore efforts should be united in OSS.
- Having a generators stdlib within ScalaCheck or hosted under the ScalaCheck organisation makes it easier to find and potentially draws more contributors.
IMO a lib hosted under the scalacheck org would be a great thing and I'd be happy to make an initial contribution and try to keep contributing over time. Let's join forces! :)
I'd like to invite everyone (who e.g. created a lib from the ones above) to share views and discuss this question. @alexarchambault @etaty @danielasfregola @47degdev @cogpp @idreeskhan (some of you I identified from libs/commits).
I totally approve! I just spend the last few hours doing that work, again! I would prefer hosted in the scalacheck organisation but not part of the core.
On Fri, 5 Apr 2019 at 13:57, Daniel Bimschas [email protected] wrote:
While that is already a great collection of generators (or generator generators), I'd like to add a different viewpoint to the statement
the opinion is to have other libraries provide more generators
and to @rickynils https://github.com/rickynils statement
Keep the current ScalaCheck lib slim (or make it even slimmer) and dependency-less. Encourage utility libraries for specialized functionality/combinators/generators etc. This does not imply that the ScalaCheck core should stop evolve/improve.
I think at the current state the "ecosystem of ScalaCheck generators" is somewhat fragmented. A first-time ScalaCheck / PBT user will only find a relatively basic (even though great) set of building blocks for composing custom domain-specific generators within ScalaCheck itself. Some thoughts related to that:
- I have experience introducing ScalaCheck both within projects and at my local Meetup group. I've seen a certain scepticism about how much effort one needs to put in writing generators to actually use ScalaCheck in a project. This contributes to increase the mental barrier for trying out PBT in the first place.
- ATM there's no comprehensive library with generators for everyday use cases. Having such a library would lower the entrance barrier and efforts related to adopting PBT / ScalaCheck.
- Writing generators for stdlib types should ideally only be done "once" as an OSS lib, one should avoid to (re)build/duplicate them for every project. Generators must be stable and well-designed as in the worst/best case the stability and correctness of your software is dependent on it. A good generator is often not trivial to write, therefore efforts should be united in OSS.
- Having a generators stdlib within ScalaCheck or hosted under the ScalaCheck organisation makes it easier to find and potentially draws more contributors.
IMO a lib hosted under the scalacheck org would be a great think and I'd be happy to make an initial contribution and try to keep contributing over time. Let's join forces! :)
I'd like to invite everyone (who e.g. created a lib from the ones above) to share views and discuss this question. @alexarchambault https://github.com/alexarchambault @etaty https://github.com/etaty @DanielaSfregola https://github.com/DanielaSfregola @47degdev https://github.com/47degdev @cogpp https://github.com/cogpp @idreeskhan https://github.com/idreeskhan (some of you I identified from libs/commits).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rickynils/scalacheck/issues/456#issuecomment-480265527, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcJcpPEebR6lZIDAmcR8aC4NOmOA8Irks5vd0g0gaJpZM4bCPKa .
Not sure if this is the right place to bring this up, but I've recently written a library to integrate the classes in the java.time library with scalacheck. It's at https://github.com/tmccarthy/intime.
It includes Arbitrary, Cogen, Choose and Shrink instances for all of the Java 8 datetime classes. It also has a set of "sensible" generators that only generate datetimes between 1900 and 2100, which covers many common test cases.
If there's interest, I'd be keen to find a way to make these part of a library under the scalacheck org.
