forked from iotaledger/iri
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path1_local_snapshots_tests.feature
156 lines (117 loc) · 7.67 KB
/
1_local_snapshots_tests.feature
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
Feature: Test Bootstrapping With LS
A test to determine whether or not nodes can bootstrap and sync correctly from Local Snapshot DBs and data DBs. One
permanode will be started containing all the relevant files/folders for a full sync upon start. Two more nodes will
be started, connected to this node and one another: One will only have a DB and local snapshot DB, while the other will
only have the local snapshot DB and the snapshot file. All three nodes should sync with one another.
And a snapshot should be taken on the node started with just a DB.
[NodeA: Permanode, NodeB: Just DB, NodeC: Just LS DB]
Scenario: PermaNode is synced
Check that the permanode has been started correctly and is synced.
#First make sure nodes are neighbored
Given "nodeA-m1" and "nodeB-m1" are neighbors
And "nodeA-m1" and "nodeC-m1" are neighbors
#Default for test is to issue 10322
When milestone 10322 is issued on "nodeA-m1"
And we wait "30" second/seconds
Then "nodeA-m1" is synced up to milestone 10322
Scenario: DB node is synced, and files contain expected values
Check that the node started with just a DB is synced correctly, and that the proper addresses and hashes have been
stored correctly.
#First make sure nodes are neighbored
Given "nodeB-m1" and "nodeA-m1" are neighbors
And "nodeB-m1" and "nodeC-m1" are neighbors
# Default for test is to issue 10323
When milestone 10323 is issued on "nodeA-m1"
#Give the node time to finish syncing properly, then make sure that the node is synced to the latest milestone.
And we wait "30" second/seconds
Then "nodeB-m1" is synced up to milestone 10323
And A local snapshot was taken on "nodeB-m1" at index 10220
When reading the local snapshot state on "nodeB-m1" returns with:
|keys |values |type |
|address |LS_TEST_STATE_ADDRESSES |staticValue |
And reading the local snapshot metadata on "nodeB-m1" returns with:
|keys |values |type |
|hashes |LS_TEST_MILESTONE_HASHES |staticValue |
Scenario: LS DB node is synced
Check that the node started with just a LS DB is synced correctly.
#First make sure nodes are neighbored
Given "nodeC-m1" and "nodeA-m1" are neighbors
And "nodeC-m1" and "nodeB-m1" are neighbors
#Default for test is to issue 10324
When milestone 10324 is issued on "nodeA-m1"
#Give the node time to finish syncing properly, then make sure that the node is synced to the latest milestone.
And we wait "120" second/seconds
Then "nodeC-m1" is synced up to milestone 10324
Scenario: Check DB for milestone hashes
Give the db-less node some time to receive the latest milestones from the permanode, then check if the milestones
are present in the new node.
#First make sure nodes are neighbored
Given "nodeC-m1" and "nodeA-m1" are neighbors
#Default for test is to issue 10325
When milestone 10325 is issued on "nodeA-m1"
And we wait "30" second/seconds
Then "checkConsistency" is called on "nodeC-m1" with:
|keys |values |type |
|tails |LS_TEST_MILESTONE_HASHES |staticValue |
And the response for "checkConsistency" should return with:
|keys |values |type |
|state |True |bool |
Scenario: Old transactions are pruned
Takes a node with a large db and transaction pruning enabled, and checks to make sure that the transactions below
the pruning depth are no longer present.
Given "getInclusionStates" is called on "nodeD-m1" with:
|keys |values |type |
|transactions |LS_PRUNED_TRANSACTIONS |staticValue |
|tips |LS_PRUNING_TIP |staticList |
And the response for "getInclusionStates" should return with:
|keys |values |type |
|states |True |boolList |
# Trigger pruning and wait for it to finish
When the next 10 milestones are issued
And we wait "15" second/seconds
And "getInclusionStates" is called on "nodeD-m1" with:
|keys |values |type |
|transactions |LS_PRUNED_TRANSACTIONS |staticValue |
|tips |LS_PRUNING_TIP |staticList |
Then the response for "getInclusionStates" should return with:
|keys |values |type |
|states |False |boolList |
Scenario: Check unconfirmed transaction is spent from
Issues a value transaction that will be unconfirmed, and check that the address was spent from.
Given a transaction is generated and attached on "nodeE-m1" with:
|keys |values |type |
|address |TEST_ADDRESS |staticValue |
|value |10 |int |
|seed |UNCONFIRMED_TEST_SEED |staticValue |
When "wereAddressesSpentFrom" is called on "nodeE-m1" with:
|keys |values |type |
|addresses |UNCONFIRMED_TEST_ADDRESS |staticValue |
Then the response for "wereAddressesSpentFrom" should return with:
|keys |values |type |
|addresses |True |boolList |
Scenario: Check addresses spent from after pruning
Ensures that a node with a spent address registers that the address is spent from both before and after the
transaction has been pruned from the DB.
# Check that addresses were spent from before pruning
Given "wereAddressesSpentFrom" is called on "nodeE-m1" with:
|keys |values |type |
|addresses |LS_SPENT_ADDRESSES |staticValue |
Then the response for "wereAddressesSpentFrom" should return with:
|keys |values |type |
|addresses |True |boolList |
#Drop the spend transactions below the pruning depth
When the next 30 milestones are issued
# Check that addresses were spent after transaction have been pruned
And "wereAddressesSpentFrom" is called on "nodeE-m1" with:
|keys |values |type |
|addresses |LS_SPENT_ADDRESSES |staticValue |
Then the response for "wereAddressesSpentFrom" should return with:
|keys |values |type |
|addresses |True |boolList |
# Check that transactions from those addresses were pruned
And "getTrytes" is called on "nodeE-m1" with:
|keys |values |type |
|hashes |LS_SPENT_TRANSACTIONS |staticValue |
Then the response for "getTrytes" should return with:
|keys |values |type |
|trytes |NULL_TRANSACTION_LIST |staticValue |