Test: (In)valid bundle regressions #1784

kwek20 · 2020-03-05T15:41:04Z

Description

Adds different cases for bundles which can be confirmed by the tangle

1590 describes 2 test which we currently cannot do in a regression test, but have as a unit test.

And at least one incomplete but valid bundle (missing an index) approves the former
Already exists: BundleValidatorTest.validateSemanticsOfBundleWithMissingTransaction
And at least one invalid bundle approves the former. (send without input)
Already exists: BundleValidatorTest.validationModeAllWithInvalidBundle

These regression tests are prepared in the file 2_disabled_transaction_tests.feature and will be usable once we have white flag implemented.

We need 2 changes to the regression tests:

Updated snapshots.txt for machine 2 (@DyrellC has the database)
Change the installation of the iota python library to the following: pip install pyota[pow] (This is required for custom pow for the test with the split bundle)

Snapshot changes are the following 2 additions:

SIDKDWQWWJHTWWBNTMQ9ERZJMCJAKWUDYBWDC9MRLX9JNBU9IPBVZCPBXQNSWWYHOBBYCDLTEIGLFOCCD;1000000
TXMPVKBDFXCCSUBRSAR9BZ9PNZRWL9NRHBIZJJEG9BHQGETCZKBVXWK9GACBJNGSKQIUZGQ9IDDDYJBZC;2000000

And corresponding removal to the rest address

Type of change

Enhancement/Test (a non-breaking change which adds functionality)

How Has This Been Tested?

Ran the tests locally.
Buildkite will fail as the database and installation isnt changed in buildkite yet

GalRogozinski · 2020-03-08T17:00:18Z

python-regression/tests/features/machine2/2_transaction_tests.feature

@@ -87,3 +87,106 @@ Feature: Test transaction confirmation
            | keys   | values | type          |
            | states | False  | boolListMixed |

+    Scenario: Valid value transfer bundle that doesnt affect ledger state
+        We want to ascertain that ledger state is always calculated correctly.
+        Even in the presence of a bundle that hadnales funds but without chaning address


Suggested change

Even in the presence of a bundle that hadnales funds but without chaning address

Even in the presence of a bundle that handles funds but without changing address

GalRogozinski · 2020-03-08T17:06:31Z

python-regression/tests/features/machine2/2_transaction_tests.feature

+        Given "getBalances" is called on "nodeA-m2" with:
+        |keys                   |values                     |type           |
+        |addresses              |FAKE_SPEND_ADDRESSES       |staticList     |
+
+        Then the response for "getBalances" should return with:
+        |keys                   |values                     |type           |
+        |balances               |0                          |int            | 


I am trying to read this test intentionally without looking at the issue

I don't really understand where FAKE_SPEND_ADDRESSES is coming from
Don't understand exactly what you are testing

FAKE_SPEND_ADDRESSES is coming from staticList, which is static_vals.py, like all other static values.

What i'm testing is described in the issue ticket, basically sending nonexistant iota backand forth, causing 0 ledger changes after applying. Which is a valid case and should be allowed. Therefor we should test it :)

I wasn't clear
I meant that by reading Gherkin, I see this value only mentioned once

I don't think I can understand why the actions you are doing before have a chance to mutate the balance on this address

What if we immediately apply balance changes instead of only per bundle? BOOM test saves us as there is no balance

GalRogozinski · 2020-03-08T17:08:53Z

python-regression/tests/features/machine2/2_transaction_tests.feature

+
+        Then the response for "getBalances" should return with:
+        |keys                   |values                     |type           |
+        |balances               |1000 0                     |intList        | 


what is this trailing 0?

its an intList, we test the balance of 2 addresses, hence receiving 2 values

GalRogozinski · 2020-03-08T17:09:13Z

python-regression/tests/features/machine2/2_transaction_tests.feature

+
+    Scenario: Split transaction over 2 bundles
+        We want to ascertain that ledger state is always calculated correctly.
+        Even when we hsare a transaction over 2 different bundles


GalRogozinski · 2020-03-12T16:57:08Z

python-regression/tests/features/machine3/3_transaction_tests.feature

+        |value                  |0                          |int            |
+        |tag                    |ZERO9VALUE                 |string         |
+
+        Then a value transaction which does not move funds is generated referencing the previous transaction with:


Suggested change

Then a value transaction which does not move funds is generated referencing the previous transaction with:

Then a value bundle which moves funds back and forth from an address is generated referencing the previous transaction with:

GalRogozinski · 2020-03-12T17:00:57Z

python-regression/tests/features/machine3/3_transaction_tests.feature

+        We want to ascertain that ledger state is always calculated correctly.
+        Even when there is a transaction used in 2 different bundles


Define clearly what a "split" bundle is

acha-bill · 2020-03-16T09:59:58Z

python-regression/tests/features/machine3/3_transaction_tests.feature

+        Then "1" transaction is issued on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |0                          |int            |
+        |tag                    |ZERO9VALUE                 |string         |
+
+        Then a value bundle which moves funds back and forth from an address is generated referencing the previous transaction with:
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |value                  |100                        |int            |  
+        |tag                    |FAKE9VALUE                 |string         |
+
+        Then a transaction is issued referencing the previous transaction
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |11                         |int            |
+        |tag                    |VALUE9TRANSACTION          |string         |


The flow of this scenario could be easier to understand if you use When, Given, And and Then more appropriately.

GalRogozinski · 2020-03-24T17:39:30Z

python-regression/tests/features/steps/transaction_steps.py

+@step(r'a split bundle is generated referencing the previous transaction with:')
+def create_split_bundle(step):
+    """
+    Create a bundle that reuses the last transaction form another bundle in its own


Suggested change

Create a bundle that reuses the last transaction form another bundle in its own

Create a bundle that reuses the last transaction from another bundle in its own

GalRogozinski · 2020-03-25T15:26:40Z

python-regression/tests/features/machine1/1_local_snapshots_tests.feature

@@ -75,7 +75,7 @@ Feature: Test Bootstrapping With LS
      |keys                       |values                   |type             |
      |state                      |True                     |bool             |

-
+  @getNodeInfo


GalRogozinski · 2020-03-25T15:27:07Z

python-regression/tests/features/machine3/3_transaction_tests.feature

+        Then "1" transaction is issued on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |0                          |int            |
+        |tag                    |ZERO9VALUE                 |string         |
+
+        Then a value bundle which moves funds back and forth from an address is generated referencing the previous transaction with:
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |value                  |100                        |int            |  
+        |tag                    |FAKE9VALUE                 |string         |
+
+        Then a transaction is issued referencing the previous transaction
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |11                         |int            |
+        |tag                    |VALUE9TRANSACTION          |string         |


GalRogozinski · 2020-03-25T17:18:21Z

python-regression/tests/features/machine3/3_transaction_tests.feature.disabled

+ Feature: Test transaction confirmation
+
+   Scenario: Invalid bundle doesnt affect ledger state
+        We want to ascertain that ledger state is always calculated correctly.
+        Even in the presence of invalid bundles being approved.
+
+        Given "1" transaction is issued on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |0                          |int            |
+        |tag                    |ZERO9VALUE                 |string         |
+
+        Then an invalid bundle is generated referencing the previous transaction
+
+        Then a transaction is issued referencing the previous transaction
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |10                         |int            |
+        |tag                    |VALUE9TRANSACTION          |string         |
+
+        #In the default test, the latest sent index will be 52. The next milestone issued should be 53.
+        When a milestone is issued with index 51 and references:
+        |keys                   |values                     |type           |
+        |transactions           |previousTransaction        |responseValue  |
+
+        #Give the node time to solidify the milestone
+        And we wait "15" second/seconds
+
+        Given "getBalances" is called on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |addresses              |TEST_EMPTY_ADDRESS         |staticList     |
+
+        Then the response for "getBalances" should return with:
+        |keys                   |values                     |type           |
+        |balances               |0                          |int            |  
+
+
+    Scenario: Incomplete bundle doesnt affect ledger state
+        We want to ascertain that ledger state is always calculated correctly.
+        Even in the presence of incomplete bundles being approved.
+
+        Then "1" transaction is issued on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |0                          |int            |
+        |tag                    |ZERO9VALUE                 |string         |
+
+        Then an incomplete bundle is generated referencing the previous transaction with:
+        |keys                   |values                     |type           |
+        |address                |TEST_EMPTY_ADDRESS         |staticValue    |
+        |tag                    |INCOMPLETE9TAG             |string         |
+
+        Then a transaction is issued referencing the previous transaction
+        |keys                   |values                     |type           |
+        |seed                   |THE_BANK                   |staticList     |
+        |address                |TEST_ADDRESS               |staticValue    |
+        |value                  |11                         |int            |
+        |tag                    |VALUE9TRANSACTION          |string         |
+
+        #In the default test, the latest sent index will be 53. The next milestone issued should be 54.
+        When a milestone is issued with index 54 and references:
+        |keys                   |values                     |type           |
+        |transactions           |previousTransaction        |responseValue  |
+
+        #Give the node time to solidify the milestone
+        And we wait "10" second/seconds
+
+        Given "getBalances" is called on "nodeA-m3" with:
+        |keys                   |values                     |type           |
+        |addresses              |TEST_EMPTY_ADDRESS         |staticList     |
+
+        Then the response for "getBalances" should return with:
+        |keys                   |values                     |type           |
+        |balances               |0                          |int            | 


can you also move this to a different PR?
Less chances we will forget about this and it will also help @acha-bill ...

GalRogozinski · 2020-03-25T17:19:09Z

python-regression/tests/features/machine3/config.yml

@@ -1,6 +1,6 @@
 defaults: &transaction_tests_config_files
-  db: https://s3.eu-central-1.amazonaws.com/iotaledger-dbfiles/dev/Transactions_Tests_db.tar
-  db_checksum: 756237276479da4b01deaa0c1211ca65a4c8ec6f081452ea7e8153648c53bd67
+  db: https://s3.eu-central-1.amazonaws.com/iotaledger-dbfiles/dev/TransactionsTestsDb.tar


Is the change to this DB documented?
Talk to @DyrellC about how to document this

GalRogozinski · 2020-03-25T17:21:08Z

python-regression/tests/features/machine4/4_api_tests.feature

@@ -173,7 +173,6 @@ Feature: Test API calls on Machine 1
 		Given "getBalances" is called on "nodeA-m4" with:
 		|keys           |values			        |type               |
 		|addresses      |TEST_EMPTY_ADDRESS	        |staticList         |
-		|threshold      |100			        |int                |


this should have been part of #1768
usually I would say to move this to another PR but I am getting soft

GalRogozinski · 2020-03-25T17:23:19Z

python-regression/tests/features/steps/transaction_steps.py

+    set_world_object(node, "firstDoubleSpend", [firstDoubleSpend.hash])
+
+@step(r'a split bundle is generated referencing the previous transaction with:')
+def create_split_bundle(step):


maybe this should be also part of #1807 ?

GalRogozinski · 2020-03-25T17:24:37Z

python-regression/util/transaction_bundle_logic/bundle_scenario_setup.py

+    re_attached_bundle = Bundle.from_tryte_strings(re_attached_trytes)
+    return [original_bundle, re_attached_bundle]
+
+def custom_attach(trytes, mwm):


part of #1807?

GalRogozinski · 2020-03-25T17:25:03Z

python-regression/util/transaction_bundle_logic/bundle_scenario_setup.py

+    bundle2.sign_inputs(KeyGenerator(seedFrom))
+    return [bundle1, bundle2]
+
+def create_split_bundles(api, seedFrom, addressFrom, addressTo, addressRest, tag, value, reference):


part of #1807?

GalRogozinski · 2020-04-07T18:23:09Z

python-regression/util/transaction_bundle_logic/bundle_scenario_setup.py

@@ -0,0 +1,82 @@
+from iota.crypto.signing import KeyGenerator
+
+from iota import Iota, ProposedTransaction, Address, Bundle, TransactionHash, \


Issue found: Unused TransactionTrytes imported from iota

GalRogozinski · 2020-04-07T18:23:10Z

python-regression/tests/features/steps/transaction_steps.py

+    argument_list = {'trunk_transaction': trunk1, 'branch_transaction': branch1,
+                     'trytes': bundles[0].as_tryte_strings(), 'min_weight_magnitude': 14}
+    firstDoubleSpend = Transaction.from_tryte_string( transactions.attach_store_and_broadcast(api, argument_list).get('trytes')[0] )
+


Issue found: Trailing whitespace

GalRogozinski · 2020-04-07T18:23:11Z

python-regression/tests/features/steps/transaction_steps.py

+
+    argument_list = {'trunk_transaction': trunk2, 'branch_transaction': branch2,
+                     'trytes': bundles[1].as_tryte_strings(), 'min_weight_magnitude': 14}
+    secondDoubleSpend = Transaction.from_tryte_string( transactions.attach_store_and_broadcast(api, argument_list).get('trytes')[0] )


Issue found: Unused variable 'secondDoubleSpend'

kwek20 requested review from GalRogozinski and DyrellC March 5, 2020 15:41

kwek20 changed the base branch from dev to release-v1.9.0 March 5, 2020 15:41

GalRogozinski suggested changes Mar 8, 2020

View reviewed changes

kwek20 force-pushed the invalid-bundle-regression branch from 363149e to a71e3f0 Compare March 10, 2020 17:51

kwek20 changed the base branch from release-v1.9.0 to dev March 10, 2020 17:52

kwek20 force-pushed the invalid-bundle-regression branch from a71e3f0 to c5bc8f6 Compare March 10, 2020 17:53

kwek20 changed the base branch from dev to release-v1.9.0 March 10, 2020 17:54

kwek20 changed the base branch from release-v1.9.0 to dev March 10, 2020 17:54

kwek20 force-pushed the invalid-bundle-regression branch from c5bc8f6 to b919e05 Compare March 10, 2020 18:00

kwek20 changed the base branch from dev to release-v1.9.0 March 10, 2020 18:00

kwek20 force-pushed the invalid-bundle-regression branch from b919e05 to 4244ea1 Compare March 10, 2020 18:14

kwek20 changed the base branch from release-v1.9.0 to dev March 11, 2020 14:59

moved regression test on top of dev

f060918

kwek20 force-pushed the invalid-bundle-regression branch from 482d496 to f060918 Compare March 11, 2020 17:41

Brord van Wierst added 10 commits March 11, 2020 18:51

Fixed db configs

8a66e5e

Fixed machine numbers

b421a5b

Removed old transactiosn test

b334ed7

Codacy review fixes

b07da67

Removed reference with gtta, removed logging

ba1a1d5

Updated rest address

bf39f74

fixed blowball config name

e56e359

Removed empty line

b824762

Removed logger from util

f9d408f

removed error logging for response check,which caused test to fial

935537f

GalRogozinski reviewed Mar 12, 2020

View reviewed changes

Brord van Wierst added 2 commits March 12, 2020 18:09

added pow module

a5d3322

fixed milestone index of split test, codacy and gal feedback

a0bb502

acha-bill reviewed Mar 16, 2020

View reviewed changes

Removed broken test to merge other tests

e47a55d

kwek20 mentioned this pull request Mar 24, 2020

[DRAFT] Test: (In)valid bundle regression: split test #1807

Open

GalRogozinski suggested changes Mar 25, 2020

View reviewed changes

Brord van Wierst added 6 commits March 25, 2020 19:50

removed HUH

819cdc4

deleted disabled tests

fca6c0b

Fixed typo

3c53541

reverter threshold deletion

7fa65d3

removed more tests

58db440

Merge branch 'dev' into invalid-bundle-regression

3fda0e0

kwek20 force-pushed the invalid-bundle-regression branch from bdd3138 to 3fda0e0 Compare March 25, 2020 19:02

Brord van Wierst added 9 commits March 25, 2020 20:07

reverted threshold v2

7b3bcaf

Removed pow requirement

0bd4452

Merge branch 'dev' into invalid-bundle-regression

301b9a3

Merge branch 'dev' into invalid-bundle-regression

df55ad1

Updated readabiility

5956887

Fixed trailing whitespaces

f7a08b7

Freaking whitespaces

b83acd3

Error in transaction step

ad79546

I swear... one more whitespace and i delete this branch

f56b21f

GalRogozinski reviewed Apr 7, 2020

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test: (In)valid bundle regressions #1784

Test: (In)valid bundle regressions #1784

kwek20 commented Mar 5, 2020 •

edited

Loading

GalRogozinski Mar 8, 2020

GalRogozinski Mar 8, 2020

kwek20 Mar 8, 2020

GalRogozinski Mar 9, 2020

kwek20 Mar 9, 2020

GalRogozinski Mar 8, 2020

kwek20 Mar 8, 2020

GalRogozinski Mar 8, 2020

GalRogozinski Mar 12, 2020

GalRogozinski Mar 12, 2020

acha-bill Mar 16, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 24, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Mar 25, 2020

GalRogozinski Apr 7, 2020

GalRogozinski Apr 7, 2020

GalRogozinski Apr 7, 2020

	Even in the presence of a bundle that hadnales funds but without chaning address
	Even in the presence of a bundle that handles funds but without changing address

	Then a value transaction which does not move funds is generated referencing the previous transaction with:
	Then a value bundle which moves funds back and forth from an address is generated referencing the previous transaction with:

		We want to ascertain that ledger state is always calculated correctly.
		Even when there is a transaction used in 2 different bundles

	Create a bundle that reuses the last transaction form another bundle in its own
	Create a bundle that reuses the last transaction from another bundle in its own

		@@ -0,0 +1,82 @@
		from iota.crypto.signing import KeyGenerator

		from iota import Iota, ProposedTransaction, Address, Bundle, TransactionHash, \

Test: (In)valid bundle regressions #1784

Are you sure you want to change the base?

Test: (In)valid bundle regressions #1784

Conversation

kwek20 commented Mar 5, 2020 • edited Loading

Description

Type of change

How Has This Been Tested?

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwek20 commented Mar 5, 2020 •

edited

Loading