Hi everyone, here is our test plan for our Token Payment Processor!
(docs/testplan: Adding a testplan for Token Payment Processor by nadimhq · Pull Request #4672 · storj/storj · GitHub)
We wanted to avoid high gas fees, delays, and in general wanted to make STORJ token payment more feasible as an option!
| Test Scenario | Test Case | Description | Comments |
|---|---|---|---|
| Transaction | Block Chain Reorg | If there is a naturally occurring chain reorg then past transactions in the old chain are deactivated due to a chain reorganization (status – pending to cancelled) | Must have early on (Alpha) |
| Minimum Confirmation | A transaction should not be called paid unless it meets the minimum number of confirmations reached (this should be visible in UI, pending until it meets minimum number of confirmations) | Must have early on (Alpha) | |
| Two Transactions | If there is a pending transaction with less than the number of required confirmations and then there is a reorg and said transaction gets overridden with a longer chain, the old pending transaction should then get removed | Must have early on (Alpha) | |
| Stale Pending Transactions | Pending transactions that have less than the number of required confirmations and have been stale for a set time should be deleted from the Satellite DB and not stored again | Must have early on (Alpha) | |
| Pending Transactions | Same as above case, except it will be again stored in DB since all pending transactions are wiped from the DB regardless if they are stale or not (in this case its not stale, just pending and waiting for the minimum # of confirmations) | Must have early on (Alpha) | |
| Required Block Confirmations | Transactions should have their required blocks for confirmation high enough so that even if there is a reorg with a pending transaction that contains f.e two chains same length in parallel, there shouldn’t be an issue | Must have early on (Alpha) | |
| Alerts | Resynced Geth Node | Geth nodes should be able to sync with the network, if a geth node resyncs it can take several days and so the token payment processor should pick up transactions during this resync. | Must have early on (Beta) |
| UI | Block Explorer Link | We should be able to view transaction link and number of confirmations given a link to block explorer | Must have early on (Alpha) |
| Transaction Detail | If user makes a transaction user should be able to see Ethereum scaling solution used for said transaction (view details) | Needed later when we implement zkSync | |
| Testing | Recreate Transactions | Using sender, receiver, nonce, and transaction fees we should be able to recreate transactions to see if there are any mempool bugs and this should also be doable using storj-up | Must have early on for testing |
| Integrating Storj-scan into Storj-up | For ease of testing it would be valuable to have storj-scan built into storj-up (may need integration with satellite for us to test) | Can be implemented later | |
| Storj-scan with testnet | As stated above, token payment processor has to work with testnet to be able to run in storj-up and use existing testnet geth node | Can be implemented | |
| Timestamp Issue | It should not be possible for two transactions on a block to share the same timestamp, however If there are two deposits with the same amount to the same address in the same block, then it would mean that they have the same timestamp and the only difference would be the transaction hash because of the different nonce (this is an issue with our current design) | Current Design, design will be changed so timestamp will not be relied on | |
| Rescan | Rescan should always start from the last fully confirmed block f.e in a reorg, so rescan should start at the height of said block | ||
| Invoice Generation | When an invoice is generated and paid, coupons should be used first, followed by STORJ balance and then lastly credit card | This invoice should be shown to our accounting team and they should be asked if said invoice looks correct |