How to write Unit tests for ERC-20 Ethereum Smart Contracts It’s very important to write unit tests for your smart contracts, same as for any development project. However, unit testing in blockchain-based solutions is often underestimated and overlooked. Last year I performed more than 200 audits of smart contracts written mostly for Ethereum, and also for Neo, Eos, Tron and Bitcoin blockchains. From what I observed, nearly half of these projects didn’t write unit tests. Such oversight often resulted in poor contract performance and various security issues identified during audit. Must-have tests Each smart contract has common parts like constructor, total supply, functions for transfer to and from, for approval, and sometimes a function for burning extra tokens. So it’s important to check your smart contract for correct initialization of all the parameters, and for reverts when you overflow or underflow total supply or other values. Also you need to check modifiers and proper rights usage. uint Here we will consider only the Ethereum smart contracts, but this also applies to other platforms as contracts have the same structure there. First, let’s test proper initialization of token and its correct transfer to some address. Tests for correct initialization are simple. You just need to create a sample contract and check for correctness of all values that must be initialized. <a href="https://medium.com/media/d81cc638db663cac2ac5245cbb16445a/href">https://medium.com/media/d81cc638db663cac2ac5245cbb16445a/href</a> Checking function is very important, because there may be issues that would cause incorrect transfers. You must make sure that recipient’s and sender’s balances will change upon transfer, try to get reverts in case function gets wrong parameters, for example, when amount being sent exceeds the sender’s balance, when contract address or invalid address is sent instead of recipient address, etc. And finally you must check that you get correct logs from event. transfer transfer <a href="https://medium.com/media/d72f48b189119d2bd8e5fbeb7fb28960/href">https://medium.com/media/d72f48b189119d2bd8e5fbeb7fb28960/href</a> function is very similar to transfer, but here you also need to test that spender has enough approved balance for sending. Here are tests when spender has less amount of funds than required for transfer. transferFrom <a href="https://medium.com/media/cd6e71cff709f3f9f030ce7c2f9ee445/href">https://medium.com/media/cd6e71cff709f3f9f030ce7c2f9ee445/href</a> function is the simplest function from ERC20 standard. There is no need to check for zero address, it’s enough to check that allowance array is correctly filled. Also if you don’t have increaseApproval or decreaseApproval functions, approve will overwrite all previous values. So we recommend using these functions as protection from unnecessary overwrites. And of course it’s important to check that you get correct logs from Approval event. approve <a href="https://medium.com/media/a9e55189cfed6d8256ac727ebbfbfb04/href">https://medium.com/media/a9e55189cfed6d8256ac727ebbfbfb04/href</a> Most smart contracts include a function for tokens left after main sale. Lots of them has a special token holder account, sometimes it’s owner account. So the best solution for burning unsold tokens is the following: get amount of tokens on holders’ address, then subtract this amount from total supply, and set amount of tokens on holders’ address to zero. This will ensure that you don’t burn all the tokens, so it’s important to lay out your token burn strategy in white paper. burning <a href="https://medium.com/media/c7a1b54914b7a0d2af91b2c4569acdef/href">https://medium.com/media/c7a1b54914b7a0d2af91b2c4569acdef/href</a> Conclusion It’s very important to test your smart contract before deploying it on main network in order to prevent issues in future. When you have written unit tests, they will guarantee that there won’t be any discrepancy between your white paper and smart contract, and your smart contract will not be hacked by calling functions which have the correct rights but they . should don’t body[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;} Best programming interview quote I've heard in a while: "The code's not done until the unit tests are done. — @brianrivard function notifyResize(height) {height = height ? height : document.documentElement.offsetHeight; var resized = false; if (window.donkey && donkey.resize) {donkey.resize(height); resized = true;}if (parent && parent._resizeIframe) {var obj = {iframe: window.frameElement, height: height}; parent._resizeIframe(obj); resized = true;}if (window.location && window.location.hash === "#amp=1" && window.parent && window.parent.postMessage) {window.parent.postMessage({sentinel: "amp", type: "embed-size", height: height}, "*");}if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.resize) {window.webkit.messageHandlers.resize.postMessage(height); resized = true;}return resized;}twttr.events.bind('rendered', function (event) {notifyResize();}); twttr.events.bind('resize', function (event) {notifyResize();});if (parent && parent._resizeIframe) {var maxWidth = parseInt(window.frameElement.getAttribute("width")); if ( 500 < maxWidth) {window.frameElement.setAttribute("width", "500");}} It’s not about just Smart Contracts, you need Unit tests for all your apps and codes, because it shows you all the ways how your app could be failed.
