move @base_node and @wallet tags to top of files

tari-project · Oct 12, 2021 · 4e78ef1 · 4e78ef1
1 parent d5e6279
commit 4e78ef1
Show file tree

Hide file tree

Showing 12 changed files with 63 additions and 77 deletions.
diff --git a/integration_tests/features/Mempool.feature b/integration_tests/features/Mempool.feature
@@ -1,7 +1,7 @@
-@mempool
+@mempool @base-node
 Feature: Mempool
 
-  @critical @base-node @flaky
+  @critical @flaky
   Scenario: Transactions are propagated through a network
     #
     # The randomness of the TX1 propagation can result in this test not passing.
@@ -18,7 +18,7 @@ Feature: Mempool
     Then TX1 is in the MEMPOOL of all nodes, where 1% can fail
 
 
-  @critical @base-node @flaky
+  @critical @flaky
   Scenario: Transactions are synced
     Given I have 2 seed nodes
     And I have a base node SENDER connected to all seed nodes
@@ -35,7 +35,7 @@ Feature: Mempool
     Then SENDER has TX1 in MINED state
     Then TX1 is in the MINED of all nodes
 
-  @base-node @broken
+  @broken
   Scenario: Clear out mempool
     Given I have 1 seed nodes
     And I have a base node SENDER connected to all seed nodes
@@ -62,7 +62,7 @@ Feature: Mempool
     Then SENDER has TX3 in MINED state
 
 
-  @critical @base-node
+  @critical
   Scenario: Double spend
     Given I have 1 seed nodes
     And I have a base node SENDER connected to all seed nodes
@@ -79,7 +79,7 @@ Feature: Mempool
     Then SENDER has TX1 in UNKNOWN state
     Then SENDER has TX2 in MINED state
 
- @long-running @base-node
+ @long-running
   Scenario: Double spend eventually ends up as not stored
     Given I have 1 seed nodes
     And I have a base node SENDER connected to all seed nodes
@@ -96,7 +96,7 @@ Feature: Mempool
     Then SENDER has TX1 in NOT_STORED state
     Then SENDER has TX2 in MINED state
 
-  @critical @base-node
+  @critical
   Scenario: Mempool clearing out invalid transactions after a reorg
     Given I do not expect all automated transactions to succeed
     Given I have a seed node SEED_A
@@ -120,8 +120,7 @@ Feature: Mempool
     Then NODE_A has TXA in NOT_STORED state
     Then NODE_A has TXB in MINED state
 
-
-  @critical @base-node
+  @critical
   Scenario: Zero-conf transactions
     Given I have 1 seed nodes
     And I have a base node SENDER connected to all seed nodes
@@ -154,7 +153,6 @@ Feature: Mempool
     Then SENDER has TX12 in MINED state
     Then SENDER has TX13 in MINED state
 
-  @base-node
   Scenario: Mempool unconfirmed transactions
     Given I have 1 seed nodes
     And I have a base node BN1 connected to all seed nodes
@@ -172,7 +170,6 @@ Feature: Mempool
     When I submit transaction TX5 to BN1
     Then I wait until base node BN1 has 5 unconfirmed transactions in its mempool
 
-  @base-node
   Scenario: Mempool unconfirmed transaction to mined transaction
     Given I have 1 seed nodes
     And I have a base node BN1 connected to all seed nodes

diff --git a/integration_tests/features/MergeMining.feature b/integration_tests/features/MergeMining.feature
@@ -1,7 +1,6 @@
-@merge-mining
+@merge-mining @base-node
   Feature: Merge Mining
 
-    @base-node
     Scenario: Merge Mining Functionality Test Without Submitting To Origin
       Given I have a seed node NODE
       And I have wallet WALLET connected to all seed nodes
@@ -13,7 +12,6 @@
       When I submit a block through proxy PROXY
       Then Proxy response block submission is valid without submitting to origin
 
-    @base-node
     Scenario: Merge Mining Functionality Test With Submitting To Origin
       Given I have a seed node NODE
       And I have wallet WALLET connected to all seed nodes
@@ -29,7 +27,7 @@
       When I ask for a block header by hash using last block header from proxy PROXY
       Then Proxy response for block header by hash is valid
 
-    @critical @base-node
+    @critical
     Scenario: Simple Merge Mining
       Given I have a seed node NODE
       And I have wallet WALLET connected to all seed nodes

diff --git a/integration_tests/features/Propagation.feature b/integration_tests/features/Propagation.feature
@@ -1,4 +1,4 @@
-@propagation
+@propagation @base-node
 Feature: Block Propagation
 
   Scenario Outline: Blocks are propagated through the network
@@ -8,19 +8,18 @@ Feature: Block Propagation
     And mining node MINER mines <NumBlocks> blocks
     Then all nodes are at height <NumBlocks>
 
-    @base-node
     Examples:
       | NumSeeds | NumNonSeeds | NumBlocks |
       | 1        | 1           | 5         |
 
-    @base-node @long-running
+    @long-running
     Examples:
       | NumSeeds | NumNonSeeds | NumBlocks |
       | 1        | 10          | 5         |
       | 4        | 10          | 5         |
       | 8        | 40          | 10        |
 
-  @critical @base-node
+  @critical
   Scenario: Simple propagation
     Given I have 2 seed nodes
     And I have 4 base nodes connected to all seed nodes
@@ -29,7 +28,7 @@ Feature: Block Propagation
     Then node MINER is at height 5
     Then all nodes are at height 5
 
-  @critical @base-node
+  @critical
   Scenario: Duplicate block is rejected
     Given I have 1 seed nodes
     And I have a base node MINER connected to all seed nodes
@@ -44,7 +43,6 @@ Feature: Block Propagation
     When I mine 1 blocks on MINER
     Then all nodes are at height 2
 
-  @base-node
   Scenario: Submit orphan
     Given I have 1 seed nodes
     And I have a base node MINER connected to all seed nodes
@@ -58,7 +56,7 @@ Feature: Block Propagation
     Then I receive an error containing 'Orphan block'
     And all nodes are at height 1
 
-  @base-node @non-sync-propagation
+  @non-sync-propagation
   Scenario: Nodes should never switch to block sync but stay synced via propagation
     Given I have 1 seed nodes
     Given I have a SHA3 miner MINER connected to all seed nodes
@@ -72,8 +70,6 @@ Feature: Block Propagation
     Given mining node MINER mines 15 blocks
     Then all nodes are at height 20
 
-
-  @base-node
   Scenario: Node should lag for while before syncing
     Given I have 1 seed nodes
     Given I have a SHA3 miner MINER connected to all seed nodes
@@ -92,7 +88,7 @@ Feature: Block Propagation
     Then node MINER is at height 7
     Then all nodes are at height 7
 
-  @base-node @critical
+  @critical
   Scenario: Pruned node should prune outputs
     Given I have 1 seed nodes
     And I have a base node SENDER connected to all seed nodes

diff --git a/integration_tests/features/Reorgs.feature b/integration_tests/features/Reorgs.feature
@@ -1,4 +1,4 @@
-@reorg
+@reorg @base-node
 Feature: Reorgs
 
   @critical
@@ -25,7 +25,7 @@ Feature: Reorgs
     And node B is at height 10
     And node C is at height 10
 
-  @critical @base-node
+  @critical
   Scenario: Node rolls back reorg on invalid block
     Given I have a seed node SA
     And I have a base node B connected to seed SA
@@ -39,7 +39,7 @@ Feature: Reorgs
     And I mine a block on B at height 4 with an invalid MMR
     Then node B is at tip BTip1
 
-  @reorg @base-node
+  @reorg
   Scenario: Pruned mode reorg simple
     Given I have a base node NODE1 connected to all seed nodes
     And I have wallet WALLET1 connected to base node NODE1
@@ -63,7 +63,7 @@ Feature: Reorgs
     When I start base node NODE1
     Then all nodes are at height 20
 
-  @critical @reorg @base-node
+  @critical @reorg
   Scenario: Pruned mode reorg past horizon
     Given I have a base node NODE1 connected to all seed nodes
     And I have wallet WALLET1 connected to base node NODE1
@@ -94,7 +94,7 @@ Feature: Reorgs
     When I submit transaction TX2 to PNODE1
     Then PNODE1 has TX2 in MEMPOOL state
 
-  @critical @reorg @base-node
+  @critical @reorg
   Scenario: Zero-conf reorg with spending
     Given I do not expect all automated transactions to succeed
     Given I have a base node NODE1 connected to all seed nodes
@@ -211,18 +211,18 @@ Feature: Reorgs
     And I connect node SEED_A1 to node SEED_B1 and wait <SYNC_TIME> seconds
     When I mine 10 blocks on SEED_A1
     Then all nodes are on the same chain tip
-    @base-node
+
     Examples:
       | X1 | Y1 | X2 | Y2 | SYNC_TIME |
       | 5  | 10 | 15 | 20 | 1        |
 
-    @long-running @base-node
+    @long-running
     Examples:
         | X1     | Y1     | X2    | Y2   | SYNC_TIME |
         | 100    | 125    | 150   | 175  | 1         |
         | 1010   | 1110   | 1210  | 1310 | 1         |
 
-  @reorg  @base-node
+  @reorg
   Scenario: Full block sync with small reorg
     Given I have a base node NODE1
     And I have wallet WALLET1 connected to base node NODE1
@@ -242,7 +242,7 @@ Feature: Reorgs
     When I start base node NODE1
     Then all nodes are on the same chain at height 12
 
-  @reorg @long-running @base-node
+  @reorg @long-running
   Scenario: Full block sync with large reorg
     Given I have a base node NODE1
     And I have wallet WALLET1 connected to base node NODE1

diff --git a/integration_tests/features/Sync.feature b/integration_tests/features/Sync.feature
@@ -1,4 +1,4 @@
-@sync
+@sync @base-node
 Feature: Block Sync
 
   Scenario Outline: Initial block sync
@@ -9,20 +9,20 @@ Feature: Block Sync
     # All nodes should sync to tip
     Then all nodes are at height <NumBlocks>
 
-    @base-node
+
     Examples:
       | NumSeeds | NumBlocks | NumSyncers |
       | 1        | 1         | 1          |
 
-    @base-node @long-running
+     @long-running
     Examples:
       | NumSeeds | NumBlocks | NumSyncers |
       | 1        | 10        | 2          |
       | 1        | 50        | 4          |
       | 8        | 40        | 8          |
 
 
-  @critical @base-node
+  @critical
   Scenario: Simple block sync
     Given I have 1 seed nodes
     Given I have a SHA3 miner MINER connected to all seed nodes
@@ -31,7 +31,7 @@ Feature: Block Sync
     # All nodes should sync to tip
     Then all nodes are at height 20
 
-  @critical @base-node
+  @critical
   Scenario: Pruned mode simple sync
     Given I have 1 seed nodes
     Given I have a SHA3 miner NODE1 connected to all seed nodes
@@ -42,7 +42,7 @@ Feature: Block Sync
     Given I have a pruned node PNODE1 connected to node NODE1 with pruning horizon set to 5
     Then all nodes are at height 20
 
-  @critical  @base-node
+  @critical
   Scenario: When a new node joins the network, it should receive all peers
     Given I have 10 seed nodes
     And I have a base node NODE1 connected to all seed nodes
@@ -52,7 +52,7 @@ Feature: Block Sync
     Then NODE2 should have 11 peers
 
 
-  @critical @base-node
+  @critical
   Scenario: Pruned mode sync test
     Given I have a seed node SEED
     Given I have a base node NODE1 connected to all seed nodes
@@ -66,7 +66,7 @@ Feature: Block Sync
     When I mine 15 blocks on PNODE2
     Then all nodes are at height 23
 
-  @long-running @flaky @base-node
+  @long-running @flaky
   Scenario: Node should not sync from pruned node
     Given I have a base node NODE1 connected to all seed nodes
     And I have a pruned node PNODE1 connected to node NODE1 with pruning horizon set to 5
@@ -104,20 +104,20 @@ Feature: Block Sync
     # Allow reorg to filter through
     When I wait <SYNC_TIME> seconds
     Then node SYNCER is at the same height as node SEED
-    @critical @base-node
+    @critical
     Examples:
       | X1  | Y1 | SYNC_TIME |
       | 101 | 10 | 1       |
 
-    @long-running @base-node
+    @long-running
     Examples:
       | X1   | Y1 | SYNC_TIME |
       | 501  | 50 | 20        |
       | 999  | 50 | 60        |
       | 1000 | 50 | 60        |
       | 1001 | 50 | 60        |
 
-  @base-node
+
   Scenario: Pruned mode network only
     Given I have a base node NODE1 connected to all seed nodes
     Given I have a pruned node PNODE1 connected to node NODE1 with pruning horizon set to 5
@@ -141,12 +141,12 @@ Feature: Block Sync
     And I have <NODES> base nodes with pruning horizon <PRUNE_HORIZON> force syncing on node BASE
     Then all nodes are at height <BLOCKS>
 
-    @critical @base-node
+    @critical
     Examples:
       | NODES | BLOCKS | PRUNE_HORIZON |
       | 5     | 10     | 0             |
 
-    @long-running @base-node
+    @long-running
     Examples:
       | NODES | BLOCKS | PRUNE_HORIZON |
       | 5     | 100    | 0             |

diff --git a/integration_tests/features/TransactionInfo.feature b/integration_tests/features/TransactionInfo.feature
@@ -1,7 +1,7 @@
-@transaction-info
+@transaction-info @wallet
 Feature: Transaction Info
 
-@long-running @wallet
+@long-running
 Scenario: Get Transaction Info
     Given I have a seed node NODE
         # TODO: This test takes an hour if only one base node is used

diff --git a/integration_tests/features/WalletMonitoring.feature b/integration_tests/features/WalletMonitoring.feature
@@ -1,7 +1,6 @@
-@wallet-monitoring
+@wallet-monitoring  @wallet
 Feature: Wallet Monitoring
 
-  @wallet
   Scenario: Wallets monitoring coinbase after a reorg
         #
         # Chain 1:
@@ -134,12 +133,12 @@ Feature: Wallet Monitoring
     When I wait 1 seconds
     Then wallets WALLET1,WALLET2 should have <numBlocks> spendable coinbase outputs
 
-    @flaky @wallet
+    @flaky
     Examples:
       | numBlocks | endBlocks |
       | 10        | 15        |
 
-    @long-running @wallet
+    @long-running
     Examples:
         | numBlocks | endBlocks |
         | 100       | 105       |