5

With Javascript tests, it is possible to access the accounts which TestRPC creates using:

contract('MetaCoin', function(accounts) {
   // tests here can access accounts[n] to get the public keys
}

But how can I use those addresses from a test written in Solidity?

3

I'd like to make a suggestion.

In the TestMetaCoin.sol example, you can see that the contract owner address is used. (See tx.origin) Therefore, I see no reason why you couldn't hard-code other account addresses in a Solidity library file and then import the library into your test. You might be then be able to use $ testrpc --account="<privatekey>,balance" [--account="<privatekey>,balance"] to ensure that the addresses in your library are re-used each time you launch.

You can do some fairly complicated things with Solidity tests. (See http://truffleframework.com/tutorials/testing-for-throws-in-solidity-tests) However, judging by the truffle docs, I get the impression that they may not be designed for your use case.

http://truffleframework.com/docs/getting_started/solidity-tests

  • That's reasonable. As I'm making progress with developing in Solidity, I'm realising that maybe .sol tests serve a different purpose than .js ones. Use solidity to test complex internal logic and JavaScript for testing contracts. – Peter Hall Jul 3 '17 at 9:20
  • I'd say that's about right. I've heard the argument made that the .js tests are essentially integration tests by virtue of their dependency on web3. While that may be true, they can be used to test complex internal contract logic just as well as a Solidity test might do. The advantages of Solidity tests are rapid development, they focus on the contract logic itself (as you say) and they require less overhead. – Max Jul 3 '17 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.