-
Notifications
You must be signed in to change notification settings - Fork 269
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
Maybe use a registry fixture to test custom registrations #77
Comments
Something like an optional registry kwarg, maybe? eg~ |
That seems like the most natural way to do it. |
I've wanted to do this the other way around. # eth_abi/__init__.py
from eth_abi.wherever import default_registry
encode_single = default_registry.encode_single
decode_single = default_registry.decode_single
... So in tests we can just have a |
Yep, I remember some conversations we had about that now. Seems reasonable. |
👍 |
* convert bash scripts to py
* convert bash scripts to py
What was wrong?
In the following integration tests that test custom registrations, our method of testing is a bit stateful since it registers then unregisters coders for the custom data type. If one test fails, that could lead to a confusing failure in another test when the registry complains that a registration already exists for the custom type:
https://github.com/ethereum/eth-abi/blob/master/tests/test_integration/test_custom_registrations.py#L69-L99
How can it be fixed?
We could modify those tests to use a fixture registry instance that is created per test run. If we want to continue to do true integration testing via
encode_single
anddecode_single
, we will probably need to modify the API to support use of a custom registry instance.The text was updated successfully, but these errors were encountered: