Daniel Karzel
Senior Developer (ehem.)
What up!
Since we recently had a Code&Play on Smart Contract development with Ethereum it was about time to move the tests for our lottery contract to the truffle development framework structure.
And since we are hipster coders, we additionally configured Travis CI, so you can now see online – and almost instantaneously – that the tests written for our lottery contract are green.
That said: Of course there is still room for improving these tests 😉
Ethereum: IDEs and test frameworks
Writing Smart Contracts for the Ethereum platform is still not as fun as it could be. Most of the problems lie in the tool stack:
- There is no established tool stack yet.
Be it Ethereum-clients, test- and development frameworks or IDEs: You are walking through a thick forest of tool-trees and you don’t know which tree you should climb to have the best view. - Out of the development tools available it is very difficult to evaluate which ones will sustain.
Even if you are on the tallest tree now, it might be cut within the next half year, or just stop growing half the way up. - Even tools that have been around for a while lack usability and features that one would expect from a modern IDE or test framework.
Some trees grew fast within the last year, but that does not change the fact that most of them are still young and there are only few developers using them seriously.
But now let’s stop ranting for a minute and take a look at what is available and what got better.
Still, when it comes to contract coding IDEs, the tool most used is Remix, also called “browser-solidity”. Although it is not quite the eye-catcher and it needs some getting used to it is a decent tool to write and deploy contracts to test-networks. It does, however, not include any test-frameworks out of the box. Apparently there are quite a few plugins for editors/IDEs like Visual Studio, IntelliJ IDEA, Atom, SublimeText out there – but for most of the plugins the integration ends at syntax highlighting for Solidity. Among them the Solidity VisualStudio plugin seems to be the one integrating the highest amount of feature.
Besides that Microsoft is driving its BAAS (blockchain as a service) platform by working on an online IDE called Ethereum Studio. Previously Ethereum Studio was free and could be accessed via Ether-Camp, but recently it cannot be accessed there any more. After digging a little bit it turns out that one has to pay to use Ethereum Studio now.
Let’s talk testing. Smart contracts are supposed to be binding agreements between parties that don’t trust each other. Thus smart contracts establish trust. At the Ethereum platform there is always money involved – be it only the transaction fees for transactions that communicate with a contract that certifies something, or be it a contract that actually manages crypto-currency sent to it. Whenever there is money involved we should test thoroughly. People don’t like when somebody takes their money in an unfair way. (They also don’t like it when somebody takes it in a fair way, but that’s a different story.)
That leads us to test frameworks. There are quite a few test-frameworks available. It is quite difficult to evaluate which framework will last on the market. Take Dapple as an example. Previously the test cases for the Lottery contract used by the Senacor SmartContractSlackDapp were written against Dapple. But it seems the project recently underwent some changes. There were no new features and bug-fixes in the last half year. Recently it was announced that the Dapple project will be continued under a new name (Dapp).
One solution for finding a path in the test-framework jungle is using a development framework. Currently there are two rather established development frameworks out there, that include test-frameworks for testing Ethereum smart contracts:
Development frameworks include test-frameworks and offer a build and deploy “pipeline” that helps developing smart contract. The downside is, that one is bound to the workflow of the development framework, which is opinionated.
At the moment Truffle seems to be the framework most in use. We hope that it will still be around for a while. With truffel, similarly with embark, you can decide to write your tests either in JavaScript (using Mocha) or in Solidity. We recommend: Don’t write them in Solidity. The documentation is too basic, and there are just no advanced examples out there. Obstacles are restrictions, as an example we can name constructor calls. It is currently not possible to pass arguments and an initial amount of money (value) to a contract’s constructor through solidity tests.
If you insist on writing your tests in Solidity you can take a look at the new Dapple project, Dapp. Previously we considered Dapple as the most advanced framework for writing tests in Solidity. Dapp was not evaluated yet.
Tests in JavaScript are based on the web3 API, so there are no restrictions on how to communicate with your contract for testing. As a developer that comes from the Java universe, the Mocha syntax needed some getting used to though…
Hopes and Dreams for the future: An IDE that combines the features of Remix with the development framework features of truffle. Network and Test integration into established tools like IntelliJ IDEA, eclipse or Visual Studio would be a great solution.
Want to give it a try?
Check out the repositories that we use for our smart contract workshops:
- Smart Contract Workshop-Setup explains how to use our Vagrant VM that contains the tool-stack we use in the workshop. You find a list of tools and basic instructions how to use them there.
- SmartContractSlackDapp contains the contract code, tests and the decentralized application.