diff --git a/integration_tests/features/Mempool.feature b/integration_tests/features/Mempool.feature index 639237ed09..5eab9f3c71 100644 --- 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 index 03ef897a1c..953772feef 100644 --- 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 index dc38c7c13f..3c1f5ef8fb 100644 --- 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 blocks Then all nodes are at height - @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 index 358abcd6d2..399218ccbf 100644 --- 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 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 index dd5f348744..8627c76b9d 100644 --- 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,12 +9,12 @@ Feature: Block Sync # All nodes should sync to tip Then all nodes are at height - @base-node + Examples: | NumSeeds | NumBlocks | NumSyncers | | 1 | 1 | 1 | - @base-node @long-running + @long-running Examples: | NumSeeds | NumBlocks | NumSyncers | | 1 | 10 | 2 | @@ -22,7 +22,7 @@ Feature: Block Sync | 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,12 +104,12 @@ Feature: Block Sync # Allow reorg to filter through When I wait 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 | @@ -117,7 +117,7 @@ Feature: Block Sync | 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 base nodes with pruning horizon force syncing on node BASE Then all nodes are at height - @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 index 9ea64c739b..aa38140836 100644 --- 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 index a02c155325..2ef8691859 100644 --- 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: @@ -48,7 +47,7 @@ Feature: Wallet Monitoring Then all COINBASE transactions for wallet WALLET_A1 and wallet WALLET_B1 have consistent but opposing validity # 18+ mins on circle ci - @long-running @wallet + @long-running Scenario: Wallets monitoring normal transactions after a reorg Given I do not expect all automated transactions to succeed # @@ -134,12 +133,12 @@ Feature: Wallet Monitoring When I wait 1 seconds Then wallets WALLET1,WALLET2 should have spendable coinbase outputs - @flaky @wallet + @flaky Examples: | numBlocks | endBlocks | | 10 | 15 | - @long-running @wallet + @long-running Examples: | numBlocks | endBlocks | | 100 | 105 | diff --git a/integration_tests/features/WalletQuery.feature b/integration_tests/features/WalletQuery.feature index a91c376753..1e27b47f99 100644 --- a/integration_tests/features/WalletQuery.feature +++ b/integration_tests/features/WalletQuery.feature @@ -1,14 +1,14 @@ -@wallet-query +@wallet-query @wallet Feature: Wallet Querying - @wallet + Scenario: As a wallet I want to query the status of utxos in blocks Given I have a seed node WalletSeedA When I mine a block on WalletSeedA with coinbase CB1 Then node WalletSeedA is at height 1 Then the UTXO CB1 has been mined according to WalletSeedA - @critical @wallet + @critical Scenario: As a wallet I want to submit a transaction # Using GRPC Given I have a seed node SeedA @@ -21,7 +21,7 @@ Feature: Wallet Querying Then the UTXO UTX1 has been mined according to SeedA - @critical @wallet + @critical Scenario: As a wallet I cannot submit a locked coinbase transaction # Using GRPC Given I have a seed node SeedA diff --git a/integration_tests/features/WalletRecovery.feature b/integration_tests/features/WalletRecovery.feature index 13603e55e3..e333a2ea17 100644 --- a/integration_tests/features/WalletRecovery.feature +++ b/integration_tests/features/WalletRecovery.feature @@ -1,7 +1,7 @@ -@wallet-recovery +@wallet-recovery @wallet Feature: Wallet Recovery - @wallet + Scenario: Wallet recovery with connected base node staying online Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -20,7 +20,6 @@ Feature: Wallet Recovery Then all nodes are at height 20 Then I wait for wallet WALLET_C to have at least 100000 uT - @wallet Scenario Outline: Multiple Wallet recovery from seed node Given I have a seed node NODE And I have wallet WALLET_A connected to all seed nodes @@ -44,7 +43,7 @@ Feature: Wallet Recovery | 10 | # fails often on circle CI - @critical @flaky @wallet + @critical @flaky Scenario: Recover one-sided payments Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes diff --git a/integration_tests/features/WalletRoutingMechanism.feature b/integration_tests/features/WalletRoutingMechanism.feature index ca2191d0a5..e93212fb44 100644 --- a/integration_tests/features/WalletRoutingMechanism.feature +++ b/integration_tests/features/WalletRoutingMechanism.feature @@ -1,4 +1,4 @@ -@wallet-routing_mechanism +@wallet-routing_mechanism @wallet Feature: Wallet Routing Mechanism @flaky @@ -32,13 +32,13 @@ Scenario Outline: Wallets transacting via specified routing mechanism only Then all wallets detect all transactions as Mined_Confirmed # TODO: This wait is needed to stop base nodes from shutting down When I wait 1 seconds - @long-running @wallet + @long-running Examples: | NumBaseNodes | NumWallets | Mechanism | | 5 | 5 | DirectAndStoreAndForward | | 5 | 5 | DirectOnly | - @long-running @wallet + @long-running Examples: | NumBaseNodes | NumWallets | Mechanism | | 5 | 5 | StoreAndForwardOnly | diff --git a/integration_tests/features/WalletTransactions.feature b/integration_tests/features/WalletTransactions.feature index f50e3a81ae..96fe0ea4a0 100644 --- a/integration_tests/features/WalletTransactions.feature +++ b/integration_tests/features/WalletTransactions.feature @@ -1,7 +1,7 @@ -@wallet-transact +@wallet-transact @wallet Feature: Wallet Transactions - @critical @wallet @flaky + @critical @flaky Scenario: Wallet sending and receiving one-sided transactions Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -31,7 +31,6 @@ Feature: Wallet Transactions Then all nodes are at height 30 Then I wait for wallet WALLET_C to have at least 1500000 uT - @wallet Scenario: Wallet imports unspent output Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -54,7 +53,7 @@ Feature: Wallet Transactions Then I wait for wallet WALLET_C to have at least 1000000 uT Then I check if last imported transactions are valid in wallet WALLET_C - @critical @wallet + @critical Scenario: Wallet imports spent outputs that become invalidated Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -85,7 +84,7 @@ Feature: Wallet Transactions # for imported UTXO's anyway so until that is decided we will just check that the imported output becomes Spent #Then I check if last imported transactions are invalid in wallet WALLET_C - @critical @flaky @wallet + @critical @flaky Scenario: Wallet imports reorged outputs that become invalidated # Chain 1 Given I have a seed node SEED_B @@ -129,7 +128,7 @@ Feature: Wallet Transactions # for imported UTXO's anyway so until that is decided we will just check that the imported output becomes invalid # Then I check if last imported transactions are invalid in wallet WALLET_IMPORTED - @critical @wallet @flaky + @critical @flaky Scenario: Wallet imports faucet UTXO Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -153,7 +152,6 @@ Feature: Wallet Transactions Then all nodes are at height 15 Then I wait for wallet WALLET_C to have at least 400000 uT - @wallet Scenario: Wallet should display all transactions made Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes @@ -176,7 +174,6 @@ Feature: Wallet Transactions Then I restart wallet WALLET_B Then I check if wallet WALLET_B has 5 transactions - @wallet Scenario: Wallet clearing out invalid transactions after a reorg # # Chain 1: @@ -231,7 +228,7 @@ Feature: Wallet Transactions When I mine 6 blocks on NODE_C Then all nodes are at height 16 - @critical @wallet + @critical Scenario: Short wallet clearing out invalid transactions after a reorg # # Chain 1: @@ -287,7 +284,7 @@ Feature: Wallet Transactions Then all nodes are at height 6 # runs 8mins on circle ci - @long-running @wallet + @long-running Scenario: Wallet SAF negotiation and cancellation with offline peers Given I have a seed node NODE And I have 1 base nodes connected to all seed nodes diff --git a/integration_tests/features/WalletTransfer.feature b/integration_tests/features/WalletTransfer.feature index d7bcfde8c9..8aa40b99e3 100644 --- a/integration_tests/features/WalletTransfer.feature +++ b/integration_tests/features/WalletTransfer.feature @@ -1,7 +1,7 @@ -@wallet-transfer +@wallet-transfer @wallet Feature: Wallet Transfer - @flaky @long-running @wallet + @flaky @long-running Scenario: As a wallet I want to submit multiple transfers Given I have a seed node NODE # Add a 2nd node otherwise initial sync will not succeed @@ -24,7 +24,7 @@ Feature: Wallet Transfer Then all nodes are at height 20 Then all wallets detect all transactions as Mined_Confirmed - @long-running @wallet + @long-running Scenario: As a wallet I want to submit transfers to myself Given I have a seed node NODE # Add a 2nd node otherwise initial sync will not succeed