Test Driving an Ethereum Solidity Contract — Iteration 0: Setup

As software developers we are sharks. If we’re not feeding on new technology, we are dying. Recently, my fine-tuned nostrils caught the whiff of paradigms caught in the digital wood chipper that is the Blockchain. Dropping everything, I swam towards it.

When running into unknown terrain your best friend is your craft. For me, a fundamental part of my craft is test driving. If I want to learn Ethereum, Solidity, and support frameworks like Truffle, the best way to do that is to test drive through a Contract. With that in mind, let’s test drive through an ERC20 Solidity contract.

Now, as many of you know, you don’t need to write your own ERC20 contracts. The wonderful OpenZeppelin framework provides for you ready-made battle tested versions of Solidity Contracts. Here’s all you need to create an ERC20 compatible token with OpenZeppelin:

OK, sure, that’s going to give you a solid Contract, but you are going to be as clueless as before. We want to be able to understand what makes up a good ERC20 Contract, and for that, the best way to do it is to test drive through what it is. With that in mind, I present to you the HelloERC Kata.

A code kata is an exercise in programming which helps programmers hone their skills through practice and repetition. — Wikipedia

I created this kata to strip down what exactly an ERC20 token was, and provide a way for me to understand all of the tools and techniques that I will need to get it to work. When I can meet all of the requirements of the kata without having to look up anything I will consider myself to have “mastered” it.

Let’s roll up our sleeves and get started.

Iteration 0 — Setup

Before I can implement the requirements to setup an ERC20 standard token, I need to setup my environment. Luckily, the Truffle and Node’s npm make that easy. Follow the links to get instructions in how to install these tools.

NOTE: There’s nothing in the requirements that specify a specific way to implement them. While there are other ways to work with Solidity, for now, I’m going to focus on leveraging Truffle, which makes the work a lot easier. Sometime in the future, I may try to implement the kata without using Truffle, to help me understand the underlying technology. Another run through the kata would be to implement it in Viper, an alternative Ethereum Contract language.

To start off, I’m going to fork the repository by clicking the Fork button on the upper right corner of my GitHub repo:

Then, from the command line, I’ll clone the repository:

Navigate to the repo and run truffle init. Notice that I have to checkout MASTER.md. The truffle init command deletes the file, and I want it to keep track of what I have to do.

NOTE: This no longer seems to work with the latest version of truffle, which now requires an empty folder in order to run truffle init. You will need to do this in another folder and copy the files created over to your cloned repo.

Next, run npm init so that I can use it to manage dependencies that we will use to make testing easier. It’s going to ask a bunch of questions to help it set up the package.json file, which it uses to keep track of our project’s dependencies.

Now that I’ve got my project setup, I’m going to commit it. One of the things that’s a good idea is to do frequent commits. That way if you go down a wrong path you can easily find your way back to a safe place in your code. Note that I’ve set up my workspace, but haven’t written any functional code yet.

As we go along I’ll be providing links to the current state of our git repo like this:

GIT: 48a3153727d5220a2d079d83e728619ae4449db5

Our next step is to create our test file. One of the cool things about truffle is that it can create basic files for you.

This creates the tile test/hello_erc20.js:

Before we run it, let’s take a look at the test that the truffle framework created. The Truffle framework adds some Solidity based secret sauce on top of the Mocha testing framework.

Normally, the first thing you’d see in a Mocha test would be a call to a describe function. Truffle adds the contract function, which makes sure that your contracts are redeployed, and provides access to the test accounts that are provided by a tool like Ganache.

Now that we have a test, let’s run it and see what happens:

All right, we’ve got a failing test. Yay, us! Well, we know that true is true, so there must be something wrong with the setup. Luckily for us, Mocha tells us what’s wrong. We don’t have a contract. Let’s create one.

This creates a basic HelloErc20.sol contract file:

Let’s run the test again and see what happens.

We’re still red, but at least we see some progress. Truffle is compiling our new Solidity Contract for us, and it’s warning us about the visibility of our contractor. Let’s fix that.

Let’s rerun the test and see what that did:

On the plus side, we’ve gotten rid of the warning, but we’re still red. Now, we need to add a migration script to our new Contract. According to the Truffle documentation:

Migrations are JavaScript files that help you deploy contracts to the Ethereum network. These files are responsible for staging your deployment tasks, and they’re written under the assumption that your deployment needs will change over time. As your project evolves, you’ll create new migration scripts to further this evolution on the blockchain. A history of previously run migrations is recorded on-chain through a special Migrations contract, detailed below.

Create the file 2_deploy_contracts.js in your project’s migrations folder and add the following:

Now that we’ve told Truffle to migration our new Contract, we need to import a reference to that Contract in our test. Add this to the top of your test script:

So what’s happening? A big part of what Truffle is doing is providing a way for you to interact with your Solidity Contracts via JavaScript. When you see the console saying “Compiling ./contracts/HelloErc20.sol”, it’s creating a file called ./build/contracts/HelloErc20.json. These files are called artifacts.

To interact with them, we need our Contracts compiled into artifacts, and then migrated into our local, development blockchain. This is what 2_deploy_contracts.js is doing with our HelloErc20 Contrat’s artifact. Now we can interact with it on our local, development blockchain via Mocha and web3.js. (More on web3 later.)

NOTE: While we are doing test driven development, and are writing “Unit Tests” using the Mocha framework, we are not doing what could be classified as either a Classical or Mocking style of TDD. Our tests are interacting with an actual Ethereum Blockchain. While there’s talk about mocking Ethereum Contracts, I haven’t seen it get off the ground. My personal preference is that it never does.

Let’s run the tests:

And with that, we’re green. Wooo!!!! High fives all ‘round. Anybody… come on… don’t leave me hanging…

Before I declare victory by committing this to git, I’m going to delete the file truffle.js. Truffle creates two config files when you run init. Since truffle-config.js is the one that runs everywhere, I’m going to keep that one. Right now we’re not using it for anything, but we will soon.

GIT: 467df5e9b785229025cd41199f35a15221f9fa9a

That’s it for Iteration 0. Next time we’ll dive into delivering some BVs (business value) focusing on creating the most basic aspects of an Ethereum token.