devBlog of Michal Zalecki

Well written set of tests plays a crucial role in delivering a reliable software. A good test suit ensures that the application works as intended and significantly reduces the number of bugs. It’s easier said than done. One of the steps to achieve this goal is adhering to boundaries of different test levels. In this article, I want to focus on the integration testing of decentralized applications that rely on web3. For integration testing, I’m able to sacrifice the speed of execution to gain the confidence that different components of the app seamlessly work together.

For me, podcasts are a great alternative to listen to music when I exercise, commute, do some chores, or cooking. Over the last few years, I’ve built up a decent-size list of almost 100 subscribed podcasts but happen to listen regularly to only a few. That’s my curated list of podcasts (not just about coding) which I think are very valuable for software developers.

There are two contexts for talking about confidentiality on the blockchain. When it comes to public and permissionless blockchains, there are projects like Monero and Zcash where privacy is the outcome of anonymous transactions. Transactions in Ethereum, the biggest smart contract blockchain, can be traced and transaction payload is readable.

Ethereum is a well-established blockchain that enables developers to create smart contracts — programs that execute on blockchain that can be triggered by transactions. People often refer to blockchain as a database but using blockchains as a data store is prohibitively expensive.

IPFS (InterPlanetary File System) is protocol establishing the peer-to-peer network with resources addressed based on their content instead of the physical location like in HTTP. IPFS gives us some guarantees of blockchains like decentralization and unalterable storage at a fraction of the price you would have to give in transaction fees. Participation in the IPFS network is free.

Nebulas is yet another platform on which you can develop smart contracts. It offers a means of using JavaScript to develop Smart Contracts — an intriguing alternative to more established solutions, such as Ethereum.

Decentralized applications present a new set of challenges. One of them is testing. Transaction lifecycle is more complex than the old-school POST request/response flow and errors are often less than helpful. Although developer experience is getting better, this puts into perspective how testing is essential.

Cee, five, ef, dee, ef, four, ow, six, seven, oh wait, it’s ow, seven, six, bee… That’s of course not the way you would like to share your Ethereum address or Swarm and IPFS content hash. You copy and send it or scan QR codes but this experience is still inferior to using easy to remember, readable names. In the same way, as DNS solved this problem for IP addresses, ENS has a goal of mitigating this issue in Ethereum ecosystem.

Why would you like to verify your smart contract? It depends. It mostly depends on your use case. It always comes down to being transparent. If I were into ICOs, I would want to make sure that the token and the crowdsale contract code enforces cryptoeconomics described in the whitepaper (or, ugh…, in the video). Open sourcing the code on GitHub is a great idea but gives no guarantees that the code in the repository is even remotely similar to the one running on-chain. It is a contract after all so it would be good to give other parties a chance to familiarize with the conditions they are going to “sign”. Verify the source code even if not everyone has programming skills to read it.

Docker is the response to an ongoing problem of differences between environments in which application runs. Whether those differences are across machines of the development team, continuous integration server, or production environment. Since you are reading this, I assume you are already more or less familiar with benefits of containerizing applications. Let’s go straight to Node.js specific bits.