Add wallet-core integration test cases

1 files changed, 53 insertions, 1 deletions

diff --git a/taler-wallet.rst b/taler-wallet.rst
index 379dba0c..11167ea9 100644
--- a/taler-wallet.rst
+++ b/taler-wallet.rst
@@ -293,8 +293,11 @@ Refunds
     }
 
 
+Integration Tests
+=================
+
 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/
 
+Test Cases
+----------
+
+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?