Add strategies to package release for generating test ABI values

[davesque]

What was wrong?

Some users have a need for hypothesis strategies similar to those used in eth-abi's test suite. These strategies could be used to generate fake data for basic Ethereum ABI types.

How was it fixed?

• Added eth_abi.tools submodule that contains new strategies to generate test data.
• Added "tools" extra requirements to be installed with pip install eth-abi[tools].
• Added documentation for using data strategies.
• Added support functions for obtaining data generators for simple types.

Cute Animal Picture

[davesque]

Left to do:

• Add support functions for getting data generators for simple types
• Add documentation

[davesque]

Some concerns I have:

• Will exposing these hypothesis strategies make it harder to update strategies used by tests since they're part of the public API?
• The issue of duplicate dependencies in setup.py is weird and I don't like the solution I came up with.

[davesque]

@pipermerriam @carver

Would like your input on this. Moving these testing strategies into the package release using the <package>.tools submodule pattern has created some interesting issues. Namely, both the tools submodule and the test suite depend on hypothesis. So it really seems proper to include the same hypothesis requirement in both the tools and test extras. However, the tests also depend on the tools submodule. So we really should include all of the tools extras in the test extras.

I put together a little hack here which tries to resolve this, but it just feels weird. Any thoughts on a better alternative?

[carver]

Yeah, it feels a little hacky, but I think any solution here will. I have some suggestions that may be incremental improvements. Will make inline...

[carver]

If we find that we like this after a while and/or it comes up in at least one more repo, then we can port the setup.py changes back to the project template.

[davesque]

@pipermerriam Yep, agreed. Work is still ongoing.

[davesque]

@pipermerriam Actually, since you pointed that out, I'm realizing that possibly very few of the testing strategies would be useful for the use case that @fubuloubu had in mind. I'm going to take an alternate approach of making some strategies that I think would suit his needs and then see which ones overlap with the testing strategies we already have. Thanks for making me take a closer look at that.

[davesque]

And as a reminder to everyone, the PR description states the changes that need to be made before the PR would be considered complete, but most of those changes still haven't been added.

[fubuloubu]

Yeah, that's a good takeaway. Really, I would only see value in generating ABI types to use as function inputs for test cases, not for the reverse (creating raw byte strings that parse to ABI types)

[carver]

And as a reminder to everyone, the PR description states the changes that need to be made before the PR would be considered complete, but most of those changes still haven't been added.

I recommend adding the [ ] after the bullets to turn them into checkboxes. (and check off any that are complete) Then the progress will be very apparent to reviewers.

[fubuloubu]

Verified the API works very well for the intended use case: https://github.com/fubuloubu/hypothesis-ethereum