JakeHillion/storj
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs/testplan: Adding a testplan for Token Payment Processor (#4672)

Browse Source 
* docs/testplan: Adding a testplan for Token Payment Processor

This testplan is going to cover the token payment processor, it will go over must haves and additional features that we can add on later.

* docs/testplan: Adding a testplan for Token Payment Processor

Updated final testplan for review

* docs/testplan: Adding a testplan for Token Payment Processor

Removed unnecessary tests related to mempool scanning

* Update token-payment-processor-testplan.md

Co-authored-by: littleskunk <jens.heimbuerge@googlemail.com>
This commit is contained in:
nadimhq 2022-10-10 09:01:14 -04:00 committed by GitHub
parent ff99392fd7
commit c921cd5ccf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docs/testplan/token-payment-processor-testplan.md Normal file
View File

@ -0,0 +1,32 @@
# Token Payment Processor Testplan
&nbsp;
## Background
This testplan is going to cover the token payment processor, it will go over must haves and additional features that we can add on later.
UI relating to token payment processing can be seen on [Billing Page](https://www.figma.com/file/HlmasFJNHxs2lzGerq3WYH/Satellite-GUI-Public?node-id=11080%3A68109) figma design.
&nbsp;
&nbsp;
| 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) |
| | 0 Confirmation | If a user broadcasts a transaction into the mempool we should display it on the satellite UI as early as possible as a pending transaction with 0 confirmations for better user experience. | Nice to have for the future, but currently we are not scanning the mempool for any pending transactions / (Beta) |
| | 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) |
| | Multiple Transactions | If a user has a pending transaction and then performs another transaction with a higher nonce using the same address, the new transaction has to wait until the previous transaction with the lower nonce is confirmed (standard behavior of geth, nothing to test for us) | Nothing to test. Keeping it in for documentation. |
| | 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 | |
| | 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 | |
| | 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) | |
| | 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 | |
| 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 |