[taler-docs] branch master updated: Add wallet-core integration test cases

[gnunet]

This is an automated email from the git hooks/post-receive script.

torsten-grote pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new ab650a3  Add wallet-core integration test cases
ab650a3 is described below

commit ab650a346997bba69ad9c45d3d86ad1fc907c8c8
Author: Torsten Grote <address@hidden>
AuthorDate: Wed May 6 11:24:58 2020 -0300

    Add wallet-core integration test cases
---
 core/api-merchant.rst           |  2 +-
 taler-merchant-api-tutorial.rst |  1 +
 taler-wallet.rst                | 54 ++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index 26c8175..34071e3 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 34064a0..f97f96c 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 379dba0..11167ea 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?

-- 
To stop receiving notification emails like this one, please contact
address@hidden.