Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Support for PropCheck #63

Open
Qqwy opened this issue Apr 7, 2020 · 2 comments
Open

Feature request: Support for PropCheck #63

Qqwy opened this issue Apr 7, 2020 · 2 comments

Comments

@Qqwy
Copy link
Contributor

Qqwy commented Apr 7, 2020

We are using Norm (amongst other places) to create a spec of all commands/events/state changes that our business domain model is able to handle.
That way we can make sure that invalid commands fail fast, as well as being able to property-test the behavior of the domain model using a generator of all valid commands.

This means that we are moving into the realm of stateful property testing, which StreamData does not support, so we would like to use the PropCheck library instead. Another advantage of PropCheck over StreamData are the metrics functions it ships with that allow you to essentially profile your generators' characteristics.

Norm currently does not support PropCheck. Because their internal data types are completely different, it also unfortunately is not possible to transform the StreamData generators into PropCheck generators after-the-fact. (StreamData generators are essentially anonymous functions and PropCheck/PropEr generators are essentially symbolic representations.)

The good news, is that StreamData and PropCheck both have many of the same primitive generators, which means that a PropCheck-implementation would be able to follow the StreamData-implementation essentially to the letter.

I see two approaches:

  1. Add PropCeck as optional dependency to Norm and (when the dependency is included) implement a protocol akin to the current Norm.Generatable.
    The advantage here is that the code of the StreamData and PropCheck-implementations can live close together, and can evolve in lock-step with Norm's own internal data representations.
    The disadvantage is a (slight) increase in maintenance.

  2. Create a separate library norm_propcheck that transforms Norm schemas into PropCheck generators.
    The disadvantage is that this library requires to peek into the internals of Norm's datatypes, which is not really kosher (and will make the library more brittle).
    The advantage is that maintenance will be separate for Norm.

I'll contribute a PR if you like (1), and build it as a separate library if you rather prefer (2).
@keathley, what do you think?

@keathley
Copy link
Member

I'd love to support PropCheck ootb. I'm happy to go with solution 1. The main problem that I see atm. is that if the user has both StreamData and PropCheck included as a dependency we might run into compilation issues. I'm sure its rare, but I know we have some services that include both libraries. We probably need a way to allow the user to choose between the two, if they're in that situation. This seems like one of the rare times when I'd advocate for using Application config to allow the user to choose between the two. But I'm open to other suggestions.

@Qqwy
Copy link
Contributor Author

Qqwy commented Apr 11, 2020

Cool! I'll start working on the PR.

🤔 One idea could be to just use a different kind of function (e.g. propcheck_gen() and maybe also introduce stream_data_gen()) to disambugate between them without having to depend on configuration settings, maybe? Or does this conflict somehow with the way Norm is currently built?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants