/
Testing tool and Form

Testing tool and Form

Owned by Dani Kumar
Last updated: Nov 12, 2024 by Jaka Minkuz



For customer's convenience we provide you with a testing tool and some other actions on your apiuser.

On left side menu, customer can than access Apiusers tab, that contains "Apiusers Test".


After following that url, customer can see his apiuser and can access different actions.

  • Form - Simulate api calls and responses
  • Test - Testing tool to test your integration of gameplay
  • Edit - Allowing to edit some apiuser data (not available)

Form:

Form allows customer to try to simulate calls to our api and select different methods with his api username and his api password, which should than generate json that customer sends to our endpoint, and on right side, there is our response. 

Testing tool:

Testing tool has two parts, that allows customer to run his integration against a series of test that simulate gameplay and some cases that should be handled.

Customer can run a test with created players under his agent, that were created using createPlayer method (you can also create player using before mentioned form) If userid and gameid is already known before, it can be inputed manually, if not, there is option to select a player and there are some gameid's of games available to agent. Session is not mandatory to be sent for tests, only if customer desires to check against it.

It consists of basic test, that sends 4 requests, balance, credit, debit and rollback. If that test is ok, customer can than run advanced test, that checks some more different cases that can happen on production and communication between both parties.

If any confusion arises while executing tests, our team is always available for support via skype.


Here you can see the explanation of the tests, which are mostly unsuccessful:
Failed possible tests

We have also added 2 tests, Customer can run at any time after completing basic test. It is suggested, you test for them at the end of integration.
First one is sending debit request to two different players, for that you will have to input Second playerid into the field for this test.
What we are testing for here is an extreme case that could happen if two players are playing on the same livecasino table. In that case, they would both recieve debit/credit requests with different or same amounts, but with the same transaction_id and round_id. Other case where this could happen is if a Customer would be taking provider from 2 different servers, where transaction_id's could also double. It is suggested to internally check for transactions or rounds on player. (for example Customer internaltransactionid = transaction_id + remote_id)

Second test is Concurrent test. We will simulate sending number of requests at the same time to check if balance is updated correctly at the end. This tries to simulate production environment, where there will be multiple requests at the same time due to multiple players playing.
Minimum number of requests needed for this test to be complete is 10, Customer can try with more, for example 40.



Last test to stress test the Customer's environment is concurrent test with wins. This test generates duplicate transactions for each request sent to the client. And number of requests will specify number of rounds (credit & debit pair) So if number of requests is 10, it will send 40 requests, with 2 identical debits and 2 identical credits in a single round, out of which only single debit and single credit are to be processed.

(NOT AVAILABLE) Edit:

Allows customer to change his apiuser password (api_password) in case it has been forgoten or lost.

Customer can also edit whitelisted ip's and change his callback.

Related content