You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/consuming_tests/blockchain_test.md
+161-2Lines changed: 161 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,165 @@ The Blockchain Test fixture format tests are included in subdirectory `blockchai
4
4
5
5
These are produced by the `StateTest` and `BlockchainTest` test specs.
6
6
7
-
## Structure
7
+
## Description
8
8
9
-
A single JSON fixture file is composed of a JSON object where each key is a different test vector, with the key string representing the test name.
9
+
The blockchain test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain.
10
+
11
+
It does so by defining a series of blocks, a pre-execution state, a post-execution state, and verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.
12
+
13
+
A single JSON fixture file is composed of a JSON object where each key-value pair is a different [`Fixture`](#fixture) test object, with the key string representing the test name.
14
+
15
+
The JSON file path plus the test name are used as the unique test identifier.
16
+
17
+
## Behavior
18
+
19
+
For each [`Fixture`](#fixture) test object in the JSON fixture file, perform the following steps:
20
+
21
+
1. Use [`network`](#-network) to configure the execution fork schedule according to the [`Fork`](./common_types.md#fork) type definition
22
+
2. Use [`pre`](#-pre-alloc) as the starting state of the execution environment for the test and calculate the state root
23
+
3. Decode [`genesisRLP`](#-genesisrlp-bytes) to obtain the genesis block header
24
+
4. Compare the genesis block header with [`genesisBlockHeader`](#-genesisblockheader-fixtureheader), if any field does not match, fail the test
25
+
5. Compare the state root calculated from [`pre`](#-pre-alloc) with the state root in the genesis block header, if they do not match, fail the test
26
+
6. Set the genesis block as the current head of the chain
27
+
7. If [`blocks`](#-blocks-listfixtureblock--null) is not `null`, and contains at least one block, perform the following steps for each [`FixtureBlock`](#fixtureblock):
28
+
1. Attempt to decode block from field [`rlp`](#-rlp-bytes), and if the block cannot be decoded:
29
+
1. If [`expectException`](#expectexception-str--null) is `null`, fail the test
30
+
2. Proceed to the next block
31
+
2. Attempt to apply the decoded block on top of the current head of the chain, and if the block cannot be applied:
32
+
1. If [`expectException`](#expectexception-str--null) is `null`, fail the test
33
+
2. Proceed to the next block
34
+
3. If [`expectException`](#expectexception-str--null) is not `null`, fail the test
35
+
4. Set the decoded block as the current head of the chain
36
+
8. Compare the hash of the current head of the chain against [`lastblockhash`](#-lastblockhash-hash), if they do not match, fail the test
37
+
9. Compare all accounts and the fields described in [`post`](#-post-alloc) against the current state, if any do not match, fail the test
0 commit comments