The parameters to are equivalent to making a normal transaction except that you do not have to sign it and it delivers the amount of gas used. (It is also possible to have a false/failed test result if all gas is used). Simply put, estimateGas runs everything the same way as when making a transaction, but instead of committing the transaction it provides the information on the cost of the transaction.
You should also note that in the case of running estimateGas on a transaction that reverts (fails), the returned gas amount will equal the total gas available in a block.
With this in mind, we can alter the above test case so that the test result is indicated by the amount of gas used:
In this new version, if the test fails, the gas spent will represent the total gas available.
Now we have established a way to run arbitrary test cases without the need to pay each time we use them. In the next part, we will also eliminate the expense of deploying the contract. But before proceeding, we must violate a statement from the Yellow Paper.
The current version of the (the specification which all clients should follow) states:
This is actually inaccurate since the reference implementations we have checked — Geth, Parity and all other implementations we know — all allow for a third type of transaction. We will abuse this fact so that we can refactor the test contract, immediately perform a test case and return results — without the need to actually deploy the contract.
How can we do that? By moving the test case into the constructor.
This example has violated the Yellow Paper specification since the transaction that created a contract has also performed a message call into that contract. One call can even create multiple contracts and perform multiple message calls to those contracts, as we will show in the stubs example later.
You must compile this contract to bytecode, first. Here is how you can achieve this with Remix IDE:
<html>
<head>
<title>Estimate gas tests</title>
</head>
<body>
<script src="https://cdn.jsdelivr.net/gh/ethereum/web3.js@1.0.0-beta.34/dist/web3.min.js" type="text/javascript"></script>
<script>
if (typeof window.web3 !== "undefined" && typeof window.web3.currentProvider !== "undefined") else
const abi = [
],
"name": "testIsTotalSupply10000",
"outputs": [],
"payable": false,
"stateMutability": "nonpayable",
"type": "function"
},
],
"payable": false,
"stateMutability": "nonpayable",
"type": "constructor"
}
];
const bytecode = "0x608060405234801561001057600080fd5b5060405160208061021d8339810180604052602081101561003057600080fd5b81019080805190602001909291905050506100508161005660201b60201c565b506100e7565b6127108173ffffffffffffffffffffffffffffffffffffffff166318160ddd6040518163ffffffff1660e01b815260040160206040518083038186803b15801561009f57600080fd5b505afa1580156100b3573d6000803e3d6000fd5b505050506040513d60208110156100c957600080fd5b8101908080519060200190929190505050146100e457600080fd5b50565b610127806100f66000396000f3fe6080604052348015600f57600080fd5b506004361060285760003560e01c806347d54a4514602d575b600080fd5b606c60048036036020811015604157600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050606e565b005b6127108173ffffffffffffffffffffffffffffffffffffffff166318160ddd6040518163ffffffff1660e01b815260040160206040518083038186803b15801560b657600080fd5b505afa15801560c9573d6000803e3d6000fd5b505050506040513d602081101560de57600080fd5b81019080805190602001909291905050501460f857600080fd5b5056fea165627a7a723058201eaa86ca0d93585836b0d06315ab78c83079efff596c1a0417c5195ad0fc9e2d0029";
async function test());
contract.deploy().estimateGas(, (err, gas) => else
});
}
</script>
<h3>Testing if ERC-721 enumerable contract has a total supply of 10.000.</h3>
<h4>Quick copy contract addresses for tests:</h4>
<b>Su Squares (passing test): </b>0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F <br/>
<b>Axie Infinity (failing test): </b>0xf5b0a3efb8e8e4c201e2a935f110eaaf3ffecb8d <br/><br/>
<input id="contractAddress" type="text" placeholder="Input contract address" />
<button onclick="test()">Test</button>
<p id="console"></p>
</body>
</html>This is an arbitrary test case written in Solidity. It can be called against arbitrary contracts, it can use arbitrary data and make arbitrary calls to other contracts.
Oh, and P.S.:
This same test case can be run against any EVM network, such as Mainnet, Wanchain, Ropsten, Hyperledger Burrow, Proof of Authority Network, as well as private chains.
Stubs and Artifacts
A stub is a specific, additional contract that is required just to validate a test subject contract. For example, if you want to validate the ability of an ERC-721 contract to transfer , you will need a contract that can receive . You can check a fully developed.
Below is a basic example for an ERC-721 receiver stub. You should note that this example assumes that the contract owns a . You can achieve this in several ways that we describe in the following section. The “giver” technique has also been implemented in the 0xcert example linked.
pragma solidity 0.5.6;
import "https://github.com/0xcert/ethereum-erc721/src/contracts/tokens/erc721.sol";
import "https://github.com/0xcert/ethereum-erc721/src/contracts/tokens/erc721-token-receiver.sol";
contract StubsAndArtifacts
function testDoesCorrectlyTransferData(
ERC721 _testSubject,
uint256 _tokenId
)
public
}
contract StubTokenReceiver is
ERC721TokenReceiver
}In the same way you can deploy stubs employing the live testing technique, you can also test contract deployments.
Limitations
The shown technique provides a much-needed method of testing deployed contracts but does not come without limitations. We need to acknowledge the limitations and offer solutions to some.
Smart contract are not accessible from within contracts, therefore, there is no way of testing them without actually performing a transaction. This means that testing whether an event is emitted is not possible with estimateGas.
What if you are testing something like transfer? To be able to transfer , you need to be the owner of or an approved party. This is not a problem for estimateGas since it does not need to be signed by a private key and therefore can be run from any address. This way, you can run the transaction as the address that actually owns the even though you do not have its private key.
What about testing the safeTransferFrom method in an ERC-721 contract with no input from any of the owners? In this case, you need a receiver similar to the one described in the Stubs and Artifacts section and with the ability to receive the . Preferably, you would want to add multiple receivers with different types of passing/failing tests. You can solve this with minimum costs. All you have to do is create and deploy a few contracts that will serve as receiver tests. Once they are deployed, you can test any ERC-721 contracts safeTransferFrom, as long as you know an existing ID of that contract, and if the contract supports the enumerable extension, this method can produce immediate results.
In practice, it would work like this: you find the owner by ID, and create an estimateGas on a safeTransferFrom with the destination of the test contract you already deployed. To show you how simple it is, we’ve compiled a working example of this method that you can check.
What about a case that involves multiple parties that need to provide approval/ownership? Well, this is a limitation that cannot always be solved completely gas-free. Still, here are two examples that show how you could do it:
- If you would like to test an ERC-721 asset that you don’t own or that has not yet been minted, but the asset is for on, your test case could run as the WETH account (with 2 million Ether available). After you purchase the token on OpenSea, you can use that token as you please.
- Another way is the approach. This method is not completely free but makes the token completely safe. You can check the to see this approach in action.
Conclusion
Live testing technique provides a complete alternative to testing with clean room tools such as Truffle. This new approach makes the entire state of the network available for your test cases. And since the way in which the test subjects were deployed is not important in your case, you can run a single test suite very easily against many deployed contracts.
Reading circle questions
- Which test situations would work better in the clean room approach and which in the live test approach?
- Does the introduction of live testing limit the usefulness of Truffle and similar tools?
- What are the benefits of using a live test approach for research on security vulnerabilities?
- What changes could be made to the (Ethereum) network client to make live testing simpler?
- Was the Ethereum Yellow Paper literally wrong, or is this a contrived interpretation?
Published at Wed, 24 Apr 2019 14:58:46 +0000
