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.
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.
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.
Truffle provides a system for managing the compilation and deployment artifacts for each network. To make an actual transaction and put a smart contract on-chain we have to provide Truffle with an appropriate configuration. We configure each network separately. From this post, you will learn how to prepare a setup and deploy to a few widely used test networks.
Depends on how you count, second and third generation blockchain applications are not bound by restrictions of underlying protocols. Programmers can create smart contracts — distributed applications with access to code-controlled accounts. Use cases go far beyond exchanging value and applies where users benefit from replacing trust between parties with code.