status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

update docs on operation testing

This commit is contained in:
protolambda 2019-05-23 11:22:10 +02:00
parent 43bb64ea1e
commit 6cd681e952
No known key found for this signature in database
GPG Key ID: EC89FDBB2B4C7623
2 changed files with 33 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
specs/test_formats/operations/README.md
View File

@ -2,9 +2,39 @@
The different kinds of operations ("transactions") are tested individually with test handlers.
The tested operation kinds are:
- [`deposits`](./deposits.md)
- More tests are work-in-progress.
## Test case format
```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.
pre: BeaconState -- state before applying the deposit
<operation-name>: <operation-object> -- the YAML encoded operation, e.g. a "ProposerSlashing", or "Deposit".
post: BeaconState -- state after applying the deposit. No value if deposit processing is aborted.
```
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.
## Condition
A handler of the `operations` should process these cases,
calling the corresponding processing implementation.
Operations:
| *`operation-name`* | *`operation-object`* | *`input name`* | *`processing call`* |
|-------------------------|----------------------|----------------------|--------------------------------------------------------|
| `attestation` | `Attestation` | `attestation` | `process_deposit(state, attestation)` |
| `attester_slashing` | `AttesterSlashing` | `attester_slashing` | `process_deposit(state, attester_slashing)` |
| `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.

18
specs/test_formats/operations/deposits.md
View File

@ -1,18 +0,0 @@
# Test format: Deposit operations
A deposit is a form of an operation (or "transaction"), modifying the state.
## Test case format
```yaml
description: string -- description of test case, purely for debugging purposes
pre: BeaconState -- state before applying the deposit
deposit: Deposit -- the deposit
post: BeaconState -- state after applying the deposit. No value if deposit processing is aborted.
```
## Condition
A `deposits` handler of the `operations` should process these cases,
calling the implementation of the `process_deposit(state, deposit)` functionality described in the spec.
The resulting state should match the expected `post` state, or if the `post` state is left blank, the handler should reject the inputs as invalid.