ZIO Test: Implement Generators for Effects #1670
Conversation
It actually matters quite a bit when testing concurrent code. As a user of the library, I want to be in control of whether the generated IO contains concurrency and interruption, so I can test concurrent code against that. E.g., consider |
|
And, of course, we can exchange "concurrency" which I wrote above with any other feature of ZIO - interruption, defects, sleeps, etc. |
|
@iravid I think maybe there is a synthesis between what we are saying. When I look at the existing generators of effects. I see us building up a trees of sub-effects that are essentially no-ops (e.g. Does that make sense? |
|
On interruption in particular there is a difference where |
| /** | ||
| * A generator of throwables. | ||
| */ | ||
| final def throwable: Gen[Random, Throwable] = |
|
What about a combinator based approach:
|
|
I like that a lot. |
|
@adamgfraser Yes, completely agree! @jdegoes @adamgfraser Yes - this is what I want! 😍 |
|
This is ready for another review. |
There was a problem hiding this comment.
Looks great to me, @adamgfraser! Will let @iravid do final signoff here.
* implement generators for effects * fix issue with Scala.js * add combinators
Implements generators for
ZIOand its various type aliases.I took a somewhat different approach from the existing generators in the test suites. I think we need to make a distinction between generators that
ZIOuses internally to test its own correctness and generators that users ofZIOshould use. I would argue that for a user, if aZIOproduces anAand doesn't perform any actual effects then it should be indistinguishable to a user how thatAwas produced (e.g. if it was there all along or created through a complex chain or transformations). If it is possible for a user to distinguish those then that is an internal error inZIOthat needs to be addressed. If this is correct then to generateZIOvalues we only need to be concerned with producing the right results and not in producing different computations to produce those results. This simplifies the implementation considerably and will also make these generators faster and shrink better for users.Internally,
ZIOcan use more complex generators to verify that various different sequences of computations produce the expected results, but that shouldn't be exposed to users. At least that is my current thinking. Interested if others have different points of view.Resolves #1653.