search

typelevel / scalacheck

Property-based testing for Scala
http://www.scalacheck.org
BSD 3-Clause "New" or "Revised" License
1.94k stars 407 forks source link

Generators library #456

Open danbim opened 5 years ago

danbim commented 5 years ago

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:

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.

ashawley commented 5 years ago

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

danbim commented 5 years ago

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

Generators for JDK stdlib types

Generators for library types

Other generators

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?

danbim commented 5 years ago

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:

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).

etaty commented 5 years ago

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 notifications@github.com 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 .

tmccarthy commented 5 years ago

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.