To open the tests, log in to Management Console, expand the WalletServiceTests node in the navigation menu displayed on the left side and click on the sub-node with your Customer name. The frame on the right side will display a drop-down menu at the top, from where you can choose a test scenario. When the scenario is selected, a new set of input fields appears below, corresponding to the input arguments of the test.
Early Testing
As the Customer goes on with the implementation of individual Wallet Service operations, they may want to try to call them, in order to check the correctness of the new code. For each service operation, method the top drop down menu offers a corresponding scenario with a name identical to the name of the operation.
To perform a call:
- Fill in the values of the displayed input fields as needed and click on the Run button to execute the call. A progress indicator will appear.
- Wait until the progress indicator disappears to ensure that the call has ended.
- Review the outcome of the call in the Result field.
NOTE 1: The values of some fields like Partner ID or sign key are pre-filled with reasonable defaults. Feel free to modify them to simulate faulty input.
NOTE 2: When the call finishes, the field Sign will contain the calculated cryptographic signature of the data it was made with.
Testing Input
The Parameter Test scenario represents a test that strives for eliminating the possibility of money loss or theft due to an acceptance of invalid input arguments. When selected, an input field Parameters will appear, which allows for choosing the parameter tested:
- Sign – most important, the cryptographic signature ensures that a hacker cannot counterfeit a fake Win request,
- Partner – for data consistency, mostly useful for Customer systems serving multiple Skins by a single service,
- Amount – for data consistency, ensures that the Wallet Service implementation handles zero Deposits / Withdrawals.
To perform the test:
- Choose the parameter to be checked and click on press the Run button to execute the test. A progress indicator will appear.
- Wait until the progress indicator disappears, to ensure that the test has ended.
- Review the outcome of the test in the Result field.
NOTE: The test will succeed only if all performed calls have finished with the expected error code.
The Money values parsing Test scenario represents a test of withdraw and deposit operations with various amounts. First withdraw one hundredth to check the smallest transferable amount. Then deposit one thousand to verify parsing without thousands separators. Additionally verify withdraw 1.1.
To perform the test:
- Fill in the values of the displayed input fields as needed and press the Run button to execute the test. A progress indicator will appear.
- Wait until the progress indicator disappears, to ensure that the test has ended.
- Review the outcome of the test in the Result field.
NOTE: The test will succeed only if the expected balance is the same as players balance at the test end.
Testing Functionality
The Withdraw-Deposit Test scenario runs a test of a normal game flow (bet + win). It first withdraws and then deposits the same small amount of money. Additionally, the test checks correctness of the balance after each operation.
The Withdraw+Rollback Test scenario runs a test of canceled game flow. It first withdraws a small amount of money, only to roll the transaction back right away. Additionally, the test checks correctness of the balance after operation.
The Duplicate Deposit Test scenario runs a test of a failed deposit and additional collect. It first deposits and then deposits again with the same reference a small amount of money. The test checks correctness of the error code (11). Additionally, the test also withdraws a small amount of money after the first deposit and then checks the correctness of balance of the second deposit response – it has to be the same as the balance after the first deposit.
To perform the test:
- Fill in the values of the displayed input fields as needed and press the Run button to execute the test. A progress indicator will appear.
- Wait until the progress indicator disappears, to ensure that the test has ended.
- Review the outcome of the test in the Result field.
Testing Performance
Even if the Customer’s Wallet Service implementation is functionally correct, they can still be denied to proceed to the production stage, due to its poor overall performance. We provide the Customers with the test used to actually measure the performance (Performance Test scenario), both to prove our statements and to allow Customers to monitor the impact of the improvements they make.
The test generates multiple parallel synchronous service operation calls for multiple players (however, it never executes more than one call for a particular player at a time). The players are chosen randomly, from among all enabled players belonging to the Customer. The service operations called are chosen randomly, too, but with a predefined probability. By default probability is determined from a ratio 2 : 1 for GetBalance : Withdraw. If the Withdraw operation is executed, then is additionally randomly chosen the Deposit operation from a ratio 10 : 1 for Withdraw : Deposit.
At the end of the run, the test reports the average and maximum processing time for each service operation, provides a log of performed activities and indicates a success or failure status. From the activities log it is possible to identify which service operation was called for which player, when the call started, what amount of money was transferred (only for Deposit and Withdraw), what error code, error message and balance the call returned and how long it took.
To perform the test:
- If desirable, adjust the total number of calls to be made (up to 500) in the field Number of calls.
- If desirable, adjust the service operations call ratio in fields next to the Call ratio labels.
- Click on the Run button to execute the test. A progress indicator will appear.
- Wait until the progress indicator disappears, to ensure that the test has ended.
- Review the outcome of the test in the Result field.
NOTE 1: The Customer is required to have created 10 players with non-zero balance in the Staging environment prior to running the test, otherwise it will refuse to run and will report a failure.
NOTE 2: The test will only succeed if all executed calls have succeeded.
NOTE 3: The service operation RollbackTransaction is not called during the test.
Comments
0 comments
Article is closed for comments.