diff options
| -rw-r--r-- | core/api-merchant.rst | 2 | ||||
| -rw-r--r-- | taler-merchant-api-tutorial.rst | 1 | ||||
| -rw-r--r-- | taler-wallet.rst | 54 |
3 files changed, 55 insertions, 2 deletions
diff --git a/core/api-merchant.rst b/core/api-merchant.rst index 26c8175d..34071e3b 100644 --- a/core/api-merchant.rst +++ b/core/api-merchant.rst @@ -938,7 +938,7 @@ Receiving Payments exchange_url: string; } - +.. _order-abort: .. http:post:: /orders/$ORDER_ID/abort Abort paying for an order and obtain a refund for coins that diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst index 34064a04..f97f96c1 100644 --- a/taler-merchant-api-tutorial.rst +++ b/taler-merchant-api-tutorial.rst @@ -279,6 +279,7 @@ This code snipped illustrates giving a refund: .. index:: repurchase +.. _repurchase: Repurchase detection and fulfillment URLs ========================================= 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? |