Payment Driver ‐ Test Scenarios

TODO: ADD ALLOWANCE TESTS

• All tests are run with multi transactions on or off (with exceptions). Check status at the end.
• Most tests execute with implied preconditions -- enough tokens and gas to cover all transactions, and low gas price.
• Status is intentionally left as TBD until the API is designed.

Test Number	Preconditions	Description	Steps	Expected Result	Associated Payment Driver Status
1	-	Single token transfer	transfer tokens from account A to account B	A and B balance changes accordingly	Ok
2	-	Multiple token transfers from A to B	do n times: transfer tokens from A to B	A and B balance changes accordingly	Ok
3	-	Token transfer to different accounts w/o duplicates	do n times: transfer tokens from A to Bn	A and B{1..n} balances change accordingly	Ok
4	-	Multiple token transfers to multiple accounts w/ duplicates	do n times: transfer tokens from A to Br(n) where r(n) is not bijective	A and all Br(n) balances change accordingly	Ok
5	insufficient gas for transaction	Single transaction when no gas on account	transfer tokens from A to B	Driver detects insufficient gas for the transaction	InsufficientGas { needed_est }
6	insufficient token for transaction	Single transaction when no token on account	transfer tokens from A to B	Driver detects insufficient token for transaction	InsufficientToken { needed_est }
7	missing private key in config	Single transaction that you can not sign	transfer tokens from A to B	Driver detects that the key is missing, A and B balances do not change	CantSign { sender_address }
8	misconfigured chain id	Single transaction	transfer tokens from A to B	Driver detects invalid / missing chain id, A and B balances do not change	Ok*
9	-	Transaction to null address	transfer tokens from A to null address	Driver detects invalid transaction, A and B balances do not change	Ok*
10	Blockchain in high gas state.	Single transaction with gas limit set low, after deadline	transfer tokens from A to B	Driver detects stuck transaction, A and B balances do not change	Ok*
11	high gas	Stuck transaction retry	Transfer tokens from A to B -> transaction is stuck due to low gas -> transaction is cancelled -> transaction is retried	The second transaction succeeds, A and B balance changes accordingly	Ok
12	gas price is manipulated as part of the test	Stuck transaction unstucks during retry	Transfer tokens from A to B -> transaction is stuck due to low gas -> transaction is cancelled (-> blockchain accepts the old transaction) -> new transaction is sent with higher gas	Driver detects the second transaction fails because the previous one passed and reckognizes that the situation is OK, A and B balance changes accordingly	Ok
13	gas price is manipulated as part of the test	Stuck transaction's retry is stuck as well, old transaction passes during second retry	Transfer tokens from A to B -> transaction is stuck due to low gas -> transaction is cancelled (-> gas price increased) -> new transaction is sent with higher gas (-> gas falls and old transaction is accepted) -> new transaction is sent with higher gas	Driver detects the third transaction fails because the previous one passed and reckognizes that the situation is OK, A and B balance changes accordingly	Ok
14	different setup: two instances of the payment driver executing conflicting transactions from one account	Single transaction w/ wrong nonce	Both instances: transfer from A to B	One instance succeeds, the other detects that the transaction failed due to wrong nonce. A and B balance changes accordingly	Ok
15	-	Load tests (for example 100000 transactions to be processed)	the same as test (4) but with large n	A and B{1..n} balances change accordingly	Ok
TBD	TBD	TBD	TBD	TBD	TBD

*Despite these being failure scenarios, they don't actually impact the functioning of the driver and thus should not be communicated as driver status, only logged.

This tests can be preformed in different configurations (for example payments generated during the run)