-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add support for mocking contract calls. #33
Labels
enhancement
New feature or request
Comments
4 tasks
pgherveou
pushed a commit
to paritytech/polkadot-sdk
that referenced
this issue
Sep 29, 2023
# Description This PR introduces two changes: - the previous `Tracing` trait has been modified to accept contract address instead of code hash (seems to be way more convenient) - a new trait `CallInterceptor` that allows intercepting contract calls; in particular the default implementation for `()` will just proceed in a standard way (after compilation optimizations, there will be no footprint of that); however, implementing type might decide to mock invocation and return `ExecResult` instead Note: one might try merging `before_call` and `intercept_call`. However, IMHO this would be bad, since it would mix two completely different abstractions - tracing without any effects and actual intervention into execution process. This will unblock working on mocking contracts utility in drink and similar tools (inkdevhub/drink#33) # Checklist - [x] My PR includes a detailed description as outlined in the "Description" section above - [ ] My PR follows the [labeling requirements](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md#process) of this project (at minimum one label for `T` required) - [x] I have made corresponding changes to the documentation (if applicable) - [x] I have added tests that prove my fix is effective or that my feature works (if applicable)
bgallois
pushed a commit
to duniter/duniter-polkadot-sdk
that referenced
this issue
Mar 25, 2024
# Description This PR introduces two changes: - the previous `Tracing` trait has been modified to accept contract address instead of code hash (seems to be way more convenient) - a new trait `CallInterceptor` that allows intercepting contract calls; in particular the default implementation for `()` will just proceed in a standard way (after compilation optimizations, there will be no footprint of that); however, implementing type might decide to mock invocation and return `ExecResult` instead Note: one might try merging `before_call` and `intercept_call`. However, IMHO this would be bad, since it would mix two completely different abstractions - tracing without any effects and actual intervention into execution process. This will unblock working on mocking contracts utility in drink and similar tools (inkdevhub/drink#33) # Checklist - [x] My PR includes a detailed description as outlined in the "Description" section above - [ ] My PR follows the [labeling requirements](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md#process) of this project (at minimum one label for `T` required) - [x] I have made corresponding changes to the documentation (if applicable) - [x] I have added tests that prove my fix is effective or that my feature works (if applicable)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The approach taken in paritytech/substrate#14678 , to support debugging contract calls, can be extended to support mocking contract calls as well.
Currently, when writing e2e tests for cases when called contract returns a specific set of values is very cumbersome. It requires creating a special contract with fixed execution logic that behaves in a certain way when called with specific arguments (or by pre-specified caller). This is time-consuming and repetitive work which is very daunting.
Imagine the following pseudo-code:
This would be a callback-based mocking, which calls the drink!-side implementation when contract execution hits these lines.
Since the callback execution happens on drink! side of things, we can deserialize input arguments (as well as state probably) and have very granular control over the mock.
The text was updated successfully, but these errors were encountered: