# Let Players Set a Wager
In this section, you will:
- Add wagers.
- Work with the Bank module.
- Handle money.
- Use mocks.
- Add integration tests.
With the introduction of game expiry in the previous section and other features, you have now addressed the cases when two players start a game and finish it, or let it expire.
In this section, you will add an extra layer to a game, with wagers or stakes. Your application already includes all the necessary modules. This section relies on the
bank module in particular.
Players choose to wager money or not, and the winner gets both wagers. The forfeiter loses their wager. To reduce complexity, start by letting players wager in the staking token of your application.
Now that no games can be left stranded, it is possible for players to safely wager on their games. How could this be implemented?
# Some initial thoughts
When thinking about implementing a wager on games, ask:
- What form will a wager take?
- Who decides on the amount of wagers?
- Where is a wager recorded?
- Is there any desirable atomicity of actions?
- At what junctures do you need to handle payments, refunds, and wins?
- Are there errors to report back?
- What event should you emit?
# Code needs
When it comes to your code:
- What Ignite CLI commands, if any, will assist you?
- How do you adjust what Ignite CLI created for you?
- Where do you make your changes?
- How would you unit-test these new elements?
- Are unit tests sufficient here?
- How would you use Ignite CLI to locally run a one-node blockchain and interact with it via the CLI to see what you get?
# New information
Add this wager value to the
StoredGame's Protobuf definition:
You can let players choose the wager they want by adding a dedicated field in the message to create a game, in
Have Ignite CLI and Protobuf recompile these two files:
Now add a helper function to
StoredGame using the Cosmos SDK
This encapsulates information about the wager (where
sdk.DefaultBondDenom is most likely
# Saving the wager
Time to ensure that the new field is saved in the storage and it is part of the creation event.
Define a new event key as a constant:
Set the actual value in the new
StoredGameas it is instantiated in the create game handler:
And in the event:
Modify the constructor among the interface definition of
x/checkers/types/message_create_game.goto avoid surprises:
Adjust the CLI client accordingly:
# Declaring expectations
On its own the
Wager field does not make players pay the wager or receive rewards. You need to add handling actions which ask the
bank module to perform the required token transfers. For that, your keeper needs to ask for a
bank instance during setup.
The only way to have access to a capability with the object-capability model of the Cosmos SDK is to be given the reference to an instance which already has this capability.
Payment handling is implemented by having your keeper hold wagers in escrow while the game is being played. The
bank module has functions to transfer tokens from any account to your module and vice-versa.
Alternatively, your keeper could burn tokens when playing and mint them again when paying out. However, this makes your blockchain's total supply falsely fluctuate. Additionally, this burning and minting may prove questionable when you later introduce IBC tokens.
Declare an interface that narrowly declares the functions from other modules that you expect for your module. The conventional file for these declarations is
bank module has many capabilities, but all you need here are two functions. Your module already expects one function of the bank keeper:
SpendableCoins (opens new window). Instead of expanding this interface, you add a new one and redeclare the extra functions you need like so:
These two functions must exactly match the functions declared in the
bank's keeper.go file (opens new window). Copy the declarations directly from the
bank's file. In Go, any object with these two functions is a
# Obtaining the capability
With your requirements declared, it is time to make sure your keeper receives a reference to a bank keeper. First add a
BankEscrowKeeper to your keeper in
BankEscrowKeeper is your newly declared narrow interface. Do not forget to adjust the constructor accordingly:
Next, update where the constructor is called and pass a proper instance of
BankKeeper. This happens in
app.BankKeeper is a full
bank keeper that also conforms to your
Finally, inform the app that your checkers module is going to hold balances in escrow by adding it to the whitelist of permitted modules:
If you compare it to the other
maccperms lines, the new line does not mention any
nil is what you need to keep in escrow. For your information, the bank creates an address for your module's escrow account. When you have the full
app, you can access it with:
# Preparing expected errors
There are several new error situations that you can enumerate with new variables:
# Money handling steps
bank now in your keeper, it is time to have your keeper handle the money. Keep this concern in its own file, as the functions are reused on play, reject, and forfeit.
Create the new file
x/checkers/keeper/wager_handler.go and add three functions to collect a wager, refund a wager, and pay winnings:
Must prefix in the function means that the transaction either takes place or a
panic is issued. If a player cannot pay the wager, it is a user-side error and the user must be informed of a failed transaction. If the module cannot pay, it means the escrow account has failed. This latter error is much more serious: an invariant may have been violated and the whole application must be terminated.
Now set up collecting a wager, paying winnings, and refunding a wager:
Collecting wagers happens on a player's first move. Therefore, differentiate between players:
When there are no moves, get the address for the black player:
Try to transfer into the escrow:
Then do the same for the red player (opens new window) when there is a single move.
Paying winnings takes place when the game has a declared winner. First get the winner. "No winner" is not an acceptable situation in this
MustPayWinnings. The caller of the function must ensure there is a winner:
Then calculate the winnings to pay:
You double the wager only if the red player has also played and therefore both players have paid their wagers. Then pay the winner:
Finally, refunding wagers takes place when the game has partially started, i.e. only one party has paid, or when the game ends in a draw. In this narrow case of
Refund the black player when there has been a single move:
If the module cannot pay, then there is a panic as the escrow has failed.
You will notice that no special case is made when the wager is zero. This is a design choice here, and which way you choose to go is up to you. Not contacting the bank unnecessarily is cheaper in gas. On the other hand, why not outsource the zero check to the bank?
# Insert wager handling
With the desired steps defined in the wager handling functions, it is time to invoke them at the right places in the message handlers.
When a player plays for the first time:
When a player wins as a result of a move:
When a player rejects a game:
When a game expires and there is a forfeit, make sure to only refund or pay full winnings when applicable. The logic needs to be adjusted:
# Unit tests
If you try running your existing tests you get a compilation error on the test keeper builder (opens new window). Passing
nil will not get you far and creating a full-fledged bank keeper would be a lot of work.
# Prepare mocks
It is better to create some mocks (opens new window). The Cosmos SDK does not offer mocks of its objects so you have to create your own. For that, the
gomock (opens new window) library is a good resource. Install it:
With the library installed, you still need to do a one time creation of the mocks. Run:
If your expected keepers change, you will have to run this command again. It can be a good idea to save the command for future reference. You may use a
Makefile for that. Ensure you install the
make tool for your computer. If you use Docker, add it to the packages and rebuild the image:
At any time, you can rebuild the mocks with:
You are going to set the expectations on this
BankEscrowKeeper mock many times, including when you do not care about the result. So it is in your interest to create helper functions that will make setting up the expectations more efficient. Create a new
bank_escrow_helpers.go file with:
# Make use of mocks
With the helpers in place, you can add a new function similar to
CheckersKeeper(t testing.TB) but which uses mocks. Keep the original function, which passes a
nil for bank.
CheckersKeeperWithMocks function takes the mock in its arguments for more versatility.
Now adjust the small functions that set up the keeper before each test. You do not need to change them for the create tests because they never call the bank. You have to do it for play, reject, and forfeit.
This function creates the mock and returns two new objects:
- The mock controller, so that the
.Finish()method can be called within the test itself. This is the function that will verify the call expectations placed on the mocks.
- The mocked bank escrow. This is the instance on which you place the call expectations.
Both objects will be used from the tests proper.
Do the same for reject (opens new window). If your forfeit unit tests do not use
setupMsgServerWithOneGameForPlayMove, then you should also create one such function the forfeit tests.
# Adjust the unit tests
With these changes, you need to adjust many unit tests for play, reject, and forfeit. For many, you may only want to make the tests pass again without checking any meaningful bank call expectations. There are different situations:
The mocked bank is not called. So you do not add any expectation, and still call the controller:
The mocked bank is called, but you do not care about how it was called:
The mocked bank is called, and you want to add call expectations:
Go ahead and make the many necessary changes as you see fit.
# Wager handler unit tests
After these adjustments, it is a good idea to add unit tests directly on the wager handling functions of the keeper. Create a new
wager_handler_test.go file. In it:
Add a setup helper function that does not create any message server:
Add tests on the
CollectWagerfunction. For instance, when the game is malformed:
Or when the black player failed to escrow the wager:
Or when the collection of a wager works:
Add similar tests to the payment of winnings from the escrow. When it fails:
Or when it works:
You will also need a test for refund (opens new window) situations.
# Add bank escrow unit tests
Now that the wager handling has been convincingly tested, you want to confirm that its functions are called at the right junctures. Add dedicated tests with message servers that confirm how the bank is called. Add them in existing files, for instance:
After doing all that, confirm that your tests run.
# Integration tests
Your unit tests pass, and they confirm that the bank is called as per your expectations. It would be nice to add further tests that use a real bank. This is possible with the help of integration tests.
Fortunately, you do not have to do this from scratch: taking inspiration from tests on the bank module (opens new window), prepare your code so as to accommodate and create a full app that will contain a bank keeper, and add new tests.
For unit tests, each function takes a
t *testing.T (opens new window) object. For integration tests, each function will be a method on a test suite that inherits from testify's suite (opens new window). This has the advantage that your test suite can have as many fields as is necessary or useful. The objects that you have used and would welcome in the suite are:
You can spread the suite's methods to different files, so as to keep consistent naming for your test files.
go test will find the suite because you add a regular test (opens new window) that initializes the suite and runs it. The test suite is then automatically initialized with its
SetupTest (opens new window) function via its parent
suite class. After that, all the methods of the test suite are run.
# Accommodate your code
Copy and adjust from the Cosmos SDK.
Define your test suite in a new
go test to it:
suite.SetupTest function, taking inspiration from the bank tests (opens new window):
SetupTest function (opens new window) is like a
beforeEach as found in other test libraries. With it, you always get a new
app in each test, without interference between them. Do not omit it (opens new window) unless you have specific reasons to do so.
It collects your
checkersModuleAddress for later use in tests that check events and balances:
You can confirm you did all this correctly by running keeper tests now, although the suite has no tests.
# Helpers for money checking
Your upcoming integration tests will include checks on wagers being paid, lost, and won, so your tests need to initialize some bank balances for your players. This is made easier with a few helpers, including a helper to confirm a bank balance.
Make a bank genesis
Balance(opens new window) type from primitives:
Declare default balances that will be useful for you:
Make your preferred bank genesis state:
Add a simple function to prepare your suite with your desired balances:
Add a function to check balances from primitives:
With the preparation done, what does an integration test method look like?
# Anatomy of an integration suite test
Now you must add integration tests for your keeper in new files. What does an integration test look like? Take the example of a simple unit test (opens new window) ported to the integration test suite:
The method has a declaration:
It is declared as a member of your test suite, and is prefixed with
Test(opens new window).
The setup can be done as you like, but just like for unit tests you ought to create a helper and use it. Here one exists already:
The action is no different from a unit test's action, other than that you get the
msgServerfrom the suite's fields:
The verification is done with
suite.Require().X, but otherwise looks similar to the shorter
require.Xof unit tests:
In fact, it is exactly the same
require(opens new window) object.
You have added an integration test that copies an existing unit test. It demonstrates the concept but is of limited additional utility.
# Extra tests
It is time to add extra tests that check money handling by the bank. Before jumping in, as you did in play unit tests you can add a method that prepares your suite's keeper with a game ready to be played on:
You will call this game from the relevant tests. You can do the same for reject (opens new window).
For the tests proper, before an action that you expect to transfer money (or not) you can verify the initial position:
After the action you can test the new balances, for instance:
How you subdivide your tests and where you insert these balance checks is up to you. You can find examples here for:
- Creating a game (opens new window).
- Playing the first move (opens new window), the second move (opens new window), including up to a resolution (opens new window). You can also check the events (opens new window).
- Failing to play a game because of a failure to pay the wager on the first move (opens new window) and the second move (opens new window).
- Rejecting a game (opens new window), including when there have been moves played (opens new window).
- Forfeiting a game (opens new window), including when there has been one move played (opens new window) or two (opens new window).
# What happened to the events?
With the new tests, you may think that the events are compromised. For instance, the event type
"transfer" normally comes with three attributes, but when the bank has made two transfers the
"transfer" event ends up with 6 attributes. This is just the way events are organized: per type, with the attributes piled in.
When checking emitted events, you need to skip over the attributes you are not checking. You can easily achieve that with Go slices (opens new window).
For instance, here
transferEvent.Attributes[6:] discards the first six attributes:
# Debug your suite
You learned in a previous section how to launch a test in debug mode. It is still possible to do so when using a suite. Depending on the versions of your Go installation and your Visual Studio Code, you can launch it in two ways:
Right-click on the arrow to the left of the suite's runner
In this case, you can only launch debug for all of the suite's test methods and not just a single one (as is possible with a simple test).
Right-click on the arrow to the left of the separate test of the suite:
This option may not be available. If being able to debug only a few tests at a time is important to you, a solution is to create more granular suites, for example using one or more test suites per file and falling back on the first option.
# Interact via the CLI
With the tests done, see what happens at the command-line.
Keep the game expiry at 5 minutes to be able to test a forfeit, as done in the previous section. Now, you need to check balances after relevant steps to test that wagers are being withheld and paid.
How much do Alice and Bob have to start with?
Create a game on which the wager will be refunded because the player playing
red did not join:
Which mentions the wager:
Confirm that the balances of both Alice and Bob are unchanged - as they have not played yet.
In this example, Alice paid no gas fees, other than the transaction costs, to create a game. The gas price is likely
0 here anyway. This is fixed in the next section.
Have Alice play:
Confirm that Alice has paid her wager:
Wait 5 minutes for the game to expire and check again:
Now create a game in which both players only play once each, i.e. where the player playing
Confirm that both Alice and Bob paid their wagers. Wait 5 minutes for the game to expire and check again:
This is correct: Bob was the winner by forfeit.
Similarly, you can test that Alice gets her wager back when Alice creates a game, Alice plays, and then Bob rejects it.
It would be difficult to test by CLI when there is a winner after a full game. That would be better tested with a GUI, or by using integration tests as you did above.
To summarize, this section has explored:
- How to work with the Bank module and handle players making wagers on games, now that the application supports live games playing to completion (with the winner claiming both wagers) or expiring through inactivity (with the inactive player forfeiting their wager as if losing), and no possibility of staked value being stranded in inactive games.
- How to add the new "wager" value, modify the "create a game" message, and add a helper function to allow players to choose the wager they want to make.
- How to save the wager by defining a new event key, modifying the create game handler and the event to set the wager value, and modifying the constructor in the
- How to add handling actions which ask the
bankmodule to perform the token transfers required by the wager, and where to invoke them in the message handlers.
- How to create a new wager-handling file with functions to collect a wager, refund a wager, and pay winnings, in which
mustprefixes indicate either a user-side error (leading to a failed transaction) or a failure of the application's escrow account (requiring the whole application be terminated).
- How to run integration tests, which requires you to first build a proper bank keeper, create new helpers, refactor your existing keeper tests, account for the new events being emitted from the bank, and add extra checks of money handling.
- How to interact with the CLI to check account balances to test that wagers are being withheld and paid.