From 6cd681e952aac4641f1e6653b339848208d62259 Mon Sep 17 00:00:00 2001 From: protolambda Date: Thu, 23 May 2019 11:22:10 +0200 Subject: [PATCH] update docs on operation testing --- specs/test_formats/operations/README.md | 36 +++++++++++++++++++++-- specs/test_formats/operations/deposits.md | 18 ------------ 2 files changed, 33 insertions(+), 21 deletions(-) delete mode 100644 specs/test_formats/operations/deposits.md diff --git a/specs/test_formats/operations/README.md b/specs/test_formats/operations/README.md index 842dc3615..a99a70788 100644 --- a/specs/test_formats/operations/README.md +++ b/specs/test_formats/operations/README.md @@ -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 +: -- 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. diff --git a/specs/test_formats/operations/deposits.md b/specs/test_formats/operations/deposits.md deleted file mode 100644 index 8f44ebb22..000000000 --- a/specs/test_formats/operations/deposits.md +++ /dev/null @@ -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.