|author||Torsten Grote <email@example.com>||2020-05-06 11:24:58 -0300|
|committer||Torsten Grote <firstname.lastname@example.org>||2020-05-06 11:24:58 -0300|
Add wallet-core integration test cases
Diffstat (limited to 'taler-wallet.rst')
1 files changed, 53 insertions, 1 deletions
diff --git a/taler-wallet.rst b/taler-wallet.rst
index 379dba0..11167ea 100644
@@ -293,8 +293,11 @@ Refunds
Integration Test Example
Integration tests can be done with the low-level wallet commands. To select which coins and denominations
to use, the wallet can dump the coins in an easy-to-process format (`CoinDumpJson <https://git.taler.net/wallet-core.git/tree/src/types/talerTypes.ts#n734>`__).
@@ -356,3 +359,52 @@ top-level command and not the subcommand:
# Update exchange /keys with time travel, value in microseconds
$ taler-wallet-cli --timetravel=1000000 --wallet-db=mydb.json exchanges update -f https://exchange.int.taler.net/
+Things we already have tests for:
+* Can the wallet recoup coins and spend them?
+ [`link <https://git.taler.net/wallet-core.git/tree/integrationtests/test-recoup.sh>`__]
+Things we still need tests for:
+* Does the wallet do retries correctly when the exchange is not reachable?
+ Or when the merchant is not reachable? Or the bank?
+ This can be tested by temporarily killing those services.
+* How does the wallet deal with processing the same ``taler://(pay|withdraw)`` URI twice?
+* Test tipping (accepting/refusing a tip)
+* Test refunds
+* Test for :ref:`session-based payments <repurchase>`
+* Test case for auto-refunds
+ (scenario where the vending machine finds out that its motor is broken,
+ so it automatically gives a refund)
+* Does the wallet report "insufficient balance" correctly
+ (as opposed to, say, crashing)?
+* Perf tests: How does the wallet handle withdrawing a *LOT* of coins?
+* Are the transaction history and pending operations reported correctly?
+Tests for things the wallet doesn't handle correctly yet:
+* What happens if the wallet double-spends a coin?
+ (Easy to test by copying the wallet DB before spending
+ and then running a spend again with the old DB).
+* What happens when a reserve is changed between accepting withdrawal
+ and actually withdrawing coins?
+ (This is harder to test. Might not be possible with the current CLI.
+ The idea would be be to have some ``--inhibit=withdraw`` flag
+ that tells the wallet to not actually withdraw,
+ so we can change the reserve state and then resume the wallet.)
+* What happens if the exchange suddenly has a completely new list of denominations on offer?
+* What happens if the exchange changes its master public key?
+ The wallet *should* handle this gracefully
+ even if we have coins with that exchange,
+ provided that the old denominations can be recouped.
+ (That one is pretty difficult!)
+* Does the wallet handle :ref:`payment aborts <order-abort>` correctly?
+There are test cases that require us to modify the communication between the wallet and exchange.
+* What does the wallet do when the exchange/merchant announce an incompatible protocol version?
+* What happens if some signature made by the exchange/merchant is garbage?
+* What if the exchange reports a double-spend and the proof it gives us is invalid?