Testing your smart contracts when building dApps is a vital part of each development process, especially for blockchain application.
Well, you don’t have to because we have a solution!
Sounds awesome, right? It is!
Step #1: Setup development environment
Before we start we need to set up our development environment. First, install infeos using the following command:
npm install infeos -g
Take note here that in order to run local EOSIO nodes both on Windows & Mac infeos use Docker.
If you already have any of these programs on your computer you can continue
- Download and install Docker Desktop for Mac
- Install Kitematic for Mac OS — the best GUI to work with your containers
- Install node.js
- Download and install Docker Desktop for Windows
- Download and install Cygwin64
- Download and install git bash (if missing)
After each installation setup your programs for use. That includes but it’s not limited to accounts, log in, configurations.
For the purpose of this tutorial, I prepared a simple EOS project which you can find here. Clone it, because we’re going to use it.
The project has all the EOS smart contracts, we need to write only the unit tests.
Step #2.1: Run an EOS node
The next step is to run a local EOS node.
That’s pretty easy when you’re using infeos.
Change the directory inside the terminal to be the folder of the cloned EOS project. When you do that just simply run:
That is going to automatically start a new local EOS node. By default, it will create a new wallet, import the keys and create a new account called infeos.
If this is your first time executing
infeos run-nodeit will take some time before the EOS docker image is downloaded.
Step #2.2: Deploy EOS smart contract
Now it’s time to compile & deploy our smart contract.
Before we do that I want to move your attention to the
contracts folder. You can see that inside we have three subfolders:
include we keep all .hpp (header) files. For our project these are
types.hpp contain all structs we’re using in our dApp.
jupiter.hpp contain all actions declarations.
rc we keep our Ricardian contracts for each action.
src are all EOS smart contracts containing the implementation of each action. We have 3 files:
warrior.cpp and ship.cpp are the contracts containing the logic. jupiter.cpp is the master contract which combines everything in one place. This is the smart contract we’re going to deploy.
Thanks to that project architecture you’re able to develop more high-quality and CPU efficiency contracts. And you need only one EOS account = less money for dApp development and running 😎
I hope it’s a bit clear now. Let’s deploy!
I have included the jupiter.wasm & jupiter.abi files so you don’t need to compile. We can move directly to deploying. Run the following command:
If everything goes well it’s time for testing!
test folder. You’ll see two files:
When you open ShipTests.js you’ll see the following code:
There are a few things I want to mention here.
infeos is providing an amazing class called EOSIOTest. It contains some helper functions that will assist you during your testing process
For example, deployerAccount returns an object of type EOSIOAccount. This object is the account which deployed the master smart contract. Thanks to it you have access to its name, base permissions (owner & active), key pairs (owner & active) and even a function called getAccountData that could return the account data directly from the blockchain.
The second thing I want to mention is that you can choose how and when the smart contract will be deployed. At the moment I recommend to deploy your smart contract through deploy.js
and then in the tests to get only its instance:
EOSIOContract is an amazing class coming from infeos which can return you an instance of every deployed EOSIO smart contract.
Let’s write and explore our first test. We’ll create a new ship:
Look at line 4:
Thanks to the contract instance coming from EOSIOContract you have access to all actions from the smart contract. Isn’t that amazing! Just choose your action and pass the needed parameters. It works like magic!
Once the action is executed it’s time to check if the created ship is the expected one. With EOSIORpc you have the power behind EOSJS. We fetch the table containing all ships and we get the last record — our ship.
The next step is to assert! Here we check if the name of the ship is the same as the one we used to create it in the first place.
Run now the test with the following command:
If the test is passing everything will be green!
Let’s move to WarriorTests.js. The structure is the same only the tests are different.
Are you a fan of Captain Marvel? Yes! Me too! Let’s create a new warrior named Carol Danvers:
Let’s create another test but this time will add a ship:
And one final test where we’re going to expect throw:
The code is the same, but take a look at:
EOSIOTest gives you a helper function called expectThrow. It takes two parameters: a function and an error message. The message will be print if addShip doesn’t throw.
Now let’s run it again
Woohoo! All tests are passing! With infeos is so easy and fast to test your EOSIO smart contracts!
Don’t hesitate to join us at our telegram group: infeos where we’ll be sharing news, releases. You can contact us there if you need help with infeos
And of course, follow us on social media for even more exciting stuff from us:
Infinite X Labs
About the author: Dimitar is CEO & Founder at Infinite X Labs and EOS Bulgaria. He’s also a lead blockchain developer. His understanding of what the business wants, combined with his extensive background in working with various blockchains helps him to find the perfect formula not only to bring ideas to life but to build solutions where they do not yet exist.