Execute contract wrapper from a separate address in web3j-unit

Heya :wave:

I’m wondering if there is an easy way to leverage the generated contract wrappers to send a transaction from an alternative address… to clarify, say I have a contract MyContract, with a function doSomething. Now, if I want to just execute doSomething in a unit test, that is relatively trivial. But, let’s say that doSomething is a payable function. If I wanted to execute this transaction from another account, say a Credential object creds, to my knowledge there is no streamlined way to do this using the generated contract wrapper. I can certainly

  1. Create a function
  2. Encode it
  3. Create a transaction
  4. Send the transaction
  5. Wait for the tx receipt

But it seems like there is a great opportunity to wrap this behavior in something like MyContract.doSomething(from = creds, amount = amount).

Curious what other people think, solutions others have come up with, etc.

1 Like

Ah ok 1 and 2 can be collapsed via MyContract.doSomething().encodeFunctionCall() which is great b/c you avoid having to mess around with ABI type wrappers directly

1 Like

Also my initial question was not quite correct… assuming that doSomething has no params, I would think an absolutely ideal situation would be to be able to call something along the lines of

MyContract.doSomething().send(txParams)

where txParams is stuff like credentials, eth amount, etc.

This may not be achievable in the current implementation due to the way that Callable works

1 Like

Hi, what I believe you are looking for is this https://docs.web3j.io/transactions/transactions_and_smart_contracts/#transacting-with-a-smart-contract

A wrapper like you described would be nice but not exist currently.

Yea I probably should have been more clear, I know you can do all this, but the action of sending a TX to a contract from a separate address is common enough that it seems to warrant a higher level of abstraction than this, particularly in the case of unit tests. I think the limitations of the Runnable interface is going to make that very difficult to achieve unfortunately