|
| 1 | +Builder Tools |
| 2 | +============= |
| 3 | + |
| 4 | + |
| 5 | +The JSON test fillers found in `eth.tools.fixtures` is a set of tools which facilitate |
| 6 | +creating standard JSON consensus tests as found in the |
| 7 | +`ethereum/tests repository <https://github.com/ethereum/tests>`_. |
| 8 | + |
| 9 | +.. note:: Only VM and state tests are supported right now. |
| 10 | + |
| 11 | + |
| 12 | +State Test Fillers |
| 13 | +------------------ |
| 14 | + |
| 15 | +Tests are generated in two steps. |
| 16 | + |
| 17 | +* First, a *test filler* is written that contains a high level description of the test case. |
| 18 | +* Subsequently, the filler is compiled to the actual test in a process called |
| 19 | + filling, mainly consisting of calculating the resulting state root. |
| 20 | + |
| 21 | +The test builder represents each stage as a nested dictionary. Helper functions are provided to |
| 22 | +assemble the filler file step by step in the correct format. The |
| 23 | +:func:`~eth.tools.fixtures.fillers.fill_test` function handles compilation and |
| 24 | +takes additional parameters that can't be inferred from the filler. |
| 25 | + |
| 26 | + |
| 27 | +Creating a Filler |
| 28 | +~~~~~~~~~~~~~~~~~ |
| 29 | + |
| 30 | +Fillers are generated in a functional fashion by piping a dictionary through a |
| 31 | +sequence of functions. |
| 32 | + |
| 33 | +.. code-block:: python |
| 34 | +
|
| 35 | + filler = pipe( |
| 36 | + setup_main_filler("test"), |
| 37 | + pre_state( |
| 38 | + (sender, "balance", 1), |
| 39 | + (receiver, "balance", 0), |
| 40 | + ), |
| 41 | + expect( |
| 42 | + networks=["Frontier"], |
| 43 | + transaction={ |
| 44 | + "to": receiver, |
| 45 | + "value": 1, |
| 46 | + "secretKey": sender_key, |
| 47 | + }, |
| 48 | + post_state=[ |
| 49 | + [sender, "balance", 0], |
| 50 | + [receiver, "balance", 1], |
| 51 | + ] |
| 52 | + ) |
| 53 | + ) |
| 54 | +
|
| 55 | +.. note:: |
| 56 | + |
| 57 | + Note that :func:`~eth.tools.fixtures.setup_filler` returns a |
| 58 | + dictionary, whereas all of the following functions such as |
| 59 | + :func:`~eth.tools.fixtures.pre_state`, |
| 60 | + :func:`~eth.tools.fixtures.expect`, expect to be passed a dictionary |
| 61 | + as their single argument and return an updated version of the dictionary. |
| 62 | + |
| 63 | + |
| 64 | +.. autofunction:: eth.tools.fixtures.fillers.common.setup_main_filler |
| 65 | + |
| 66 | + This function kicks off the filler generation process by creating the general filler scaffold with |
| 67 | + a test name and general information about the testing environment. |
| 68 | + |
| 69 | + For tests for the main chain, the `environment` parameter is expected to be a dictionary with some |
| 70 | + or all of the following keys: |
| 71 | + |
| 72 | + +------------------------+---------------------------------+ |
| 73 | + | key | description | |
| 74 | + +========================+=================================+ |
| 75 | + | ``"currentCoinbase"`` | the coinbase address | |
| 76 | + +------------------------+---------------------------------+ |
| 77 | + | ``"currentNumber"`` | the block number | |
| 78 | + +------------------------+---------------------------------+ |
| 79 | + | ``"previousHash"`` | the hash of the parent block | |
| 80 | + +------------------------+---------------------------------+ |
| 81 | + | ``"currentDifficulty"``| the block's difficulty | |
| 82 | + +------------------------+---------------------------------+ |
| 83 | + | ``"currentGasLimit"`` | the block's gas limit | |
| 84 | + +------------------------+---------------------------------+ |
| 85 | + | ``"currentTimestamp"`` | the timestamp of the block | |
| 86 | + +------------------------+---------------------------------+ |
| 87 | + |
| 88 | + |
| 89 | +.. autofunction:: eth.tools.fixtures.fillers.pre_state |
| 90 | + |
| 91 | + This function specifies the state prior to the test execution. Multiple invocations don't override |
| 92 | + the state but extend it instead. |
| 93 | + |
| 94 | + In general, the elements of `state_definitions` are nested dictionaries of the following form: |
| 95 | + |
| 96 | + .. code-block:: python |
| 97 | +
|
| 98 | + { |
| 99 | + address: { |
| 100 | + "nonce": <account nonce>, |
| 101 | + "balance": <account balance>, |
| 102 | + "code": <account code>, |
| 103 | + "storage": { |
| 104 | + <storage slot>: <storage value> |
| 105 | + } |
| 106 | + } |
| 107 | + } |
| 108 | +
|
| 109 | + To avoid unnecessary nesting especially if only few fields per account are specified, the following |
| 110 | + and similar formats are possible as well: |
| 111 | + |
| 112 | + .. code-block:: python |
| 113 | +
|
| 114 | + (address, "balance", <account balance>) |
| 115 | + (address, "storage", <storage slot>, <storage value>) |
| 116 | + (address, "storage", {<storage slot>: <storage value>}) |
| 117 | + (address, {"balance", <account balance>}) |
| 118 | +
|
| 119 | +
|
| 120 | +.. autofunction:: eth.tools.fixtures.fillers.execution |
| 121 | + |
| 122 | + For VM tests, this function specifies the code that is being run as well as the current state of |
| 123 | + the EVM. State tests don't support this object. The parameter is a dictionary specifying some or |
| 124 | + all of the following keys: |
| 125 | + |
| 126 | + +--------------------+------------------------------------------------------------+ |
| 127 | + | key | description | |
| 128 | + +====================+============================================================+ |
| 129 | + | ``"address"`` | the address of the account executing the code | |
| 130 | + +--------------------+------------------------------------------------------------+ |
| 131 | + | ``"caller"`` | the caller address | |
| 132 | + +--------------------+------------------------------------------------------------+ |
| 133 | + | ``"origin"`` | the origin address (defaulting to the caller address) | |
| 134 | + +--------------------+------------------------------------------------------------+ |
| 135 | + | ``"value"`` | the value of the call | |
| 136 | + +--------------------+------------------------------------------------------------+ |
| 137 | + | ``"data"`` | the data passed with the call | |
| 138 | + +--------------------+------------------------------------------------------------+ |
| 139 | + | ``"gasPrice"`` | the gas price of the call | |
| 140 | + +--------------------+------------------------------------------------------------+ |
| 141 | + | ``"gas"`` | the amount of gas allocated for the call | |
| 142 | + +--------------------+------------------------------------------------------------+ |
| 143 | + | ``"code"`` | the bytecode to execute | |
| 144 | + +--------------------+------------------------------------------------------------+ |
| 145 | + | ``"vyperLLLCode"`` | the code in Vyper LLL (compiled to bytecode automatically) | |
| 146 | + +--------------------+------------------------------------------------------------+ |
| 147 | + |
| 148 | + |
| 149 | +.. autofunction:: eth.tools.fixtures.fillers.expect |
| 150 | + |
| 151 | + This specifies the expected result of the test. |
| 152 | + |
| 153 | + For state tests, multiple expectations can be given, differing in the transaction data, gas |
| 154 | + limit, and value, in the applicable networks, and as a result also in the post state. VM tests |
| 155 | + support only a single expectation with no specified network and no transaction (here, its role is |
| 156 | + played by :func:`~eth.tools.fixtures.fillers.execution`). |
| 157 | + |
| 158 | + * ``post_state`` is a list of state definition in the same form as expected by `pre_state`. State items |
| 159 | + that are not set explicitly default to their pre state. |
| 160 | + |
| 161 | + * ``networks`` defines the forks under which the expectation is applicable. It should be a sublist of |
| 162 | + the following identifiers (also available in `ALL_FORKS`): |
| 163 | + |
| 164 | + * ``"Frontier"`` |
| 165 | + * ``"Homestead"`` |
| 166 | + * ``"EIP150"`` |
| 167 | + * ``"EIP158"`` |
| 168 | + * ``"Byzantium"`` |
| 169 | + |
| 170 | + * ``transaction`` is a dictionary coming in two variants. For the main shard: |
| 171 | + |
| 172 | + +----------------+-------------------------------+ |
| 173 | + | key | description | |
| 174 | + +================+===============================+ |
| 175 | + | ``"data"`` | the transaction data, | |
| 176 | + +----------------+-------------------------------+ |
| 177 | + | ``"gasLimit"`` | the transaction gas limit, | |
| 178 | + +----------------+-------------------------------+ |
| 179 | + | ``"gasPrice"`` | the gas price, | |
| 180 | + +----------------+-------------------------------+ |
| 181 | + | ``"nonce"`` | the transaction nonce, | |
| 182 | + +----------------+-------------------------------+ |
| 183 | + | ``"value"`` | the transaction value | |
| 184 | + +----------------+-------------------------------+ |
| 185 | + |
| 186 | + In addition, one should specify either the signature itself (via keys ``"v"``, ``"r"``, and ``"s"``) or |
| 187 | + a private key used for signing (via ``"secretKey"``). |
0 commit comments