2019-04-12 12:19:10 +00:00
|
|
|
# Operations tests
|
|
|
|
|
|
|
|
|
|
The different kinds of operations ("transactions") are tested individually with test handlers.
|
|
|
|
|
|
2019-05-23 09:22:10 +00:00
|
|
|
## Test case format
|
2019-04-12 12:19:10 +00:00
|
|
|
|
2019-05-23 09:22:10 +00:00
|
|
|
```yaml
|
|
|
|
|
description: string -- description of test case, purely for debugging purposes
|
|
|
|
|
bls_required: bool -- optional, true if the test validity is strictly dependent on BLS being ON. False otherwise.
|
|
|
|
|
bls_ignored: bool -- optional, true if the test validity is strictly dependent on BLS being OFF. False otherwise.
|
2019-05-23 22:13:49 +00:00
|
|
|
pre: BeaconState -- state before applying the operation
|
2019-05-23 09:22:10 +00:00
|
|
|
<operation-name>: <operation-object> -- the YAML encoded operation, e.g. a "ProposerSlashing", or "Deposit".
|
2019-05-23 22:13:49 +00:00
|
|
|
post: BeaconState -- state after applying the operation. No value if operation processing is aborted.
|
2019-05-23 09:22:10 +00:00
|
|
|
```
|
2019-04-12 12:15:30 +00:00
|
|
|
|
2019-05-23 09:22:10 +00:00
|
|
|
Note: if both `bls_required` and `bls_ignored` are false (or simply not included),
|
|
|
|
|
then the test consumer can freely choose to run with BLS ON or OFF.
|
|
|
|
|
One may choose for OFF for performance reasons during repeated testing. Otherwise it is recommended to run with BLS ON.
|
2019-04-12 12:15:30 +00:00
|
|
|
|
2019-05-23 09:22:10 +00:00
|
|
|
## Condition
|
|
|
|
|
|
2019-05-23 22:13:49 +00:00
|
|
|
A handler of the `operations` test-runner should process these cases,
|
2019-05-23 09:22:10 +00:00
|
|
|
calling the corresponding processing implementation.
|
|
|
|
|
|
|
|
|
|
Operations:
|
|
|
|
|
|
|
|
|
|
| *`operation-name`* | *`operation-object`* | *`input name`* | *`processing call`* |
|
|
|
|
|
|-------------------------|----------------------|----------------------|--------------------------------------------------------|
|
2019-05-24 12:33:06 +00:00
|
|
|
| `attestation` | `Attestation` | `attestation` | `process_attestation(state, attestation)` |
|
2019-05-24 12:32:54 +00:00
|
|
|
| `attester_slashing` | `AttesterSlashing` | `attester_slashing` | `process_attester_slashing(state, attester_slashing)` |
|
2019-05-23 09:22:10 +00:00
|
|
|
| `block_header` | `Block` | `block` | `process_block_header(state, block)` |
|
|
|
|
|
| `deposit` | `Deposit` | `deposit` | `process_deposit(state, deposit)` |
|
|
|
|
|
| `proposer_slashing` | `ProposerSlashing` | `proposer_slashing` | `process_proposer_slashing(state, proposer_slashing)` |
|
|
|
|
|
| `transfer` | `Transfer` | `transfer` | `process_transfer(state, transfer)` |
|
|
|
|
|
| `voluntary_exit` | `VoluntaryExit` | `voluntary_exit` | `process_voluntary_exit(state, voluntary_exit)` |
|
|
|
|
|
|
|
|
|
|
Note that `block_header` is not strictly an operation (and is a full `Block`), but processed in the same manner, and hence included here.
|
|
|
|
|
|
|
|
|
|
The resulting state should match the expected `post` state, or if the `post` state is left blank,
|
|
|
|
|
the handler should reject the input operation as invalid.
|
