Event‐driven Testing: Introduction
Smart contract testing is essential to DApp development because smart contracts are immutable programs. Once a contract is deployed, it cannot be altered. If you create a contract with vulnerability, it is there forever.
On the Ethereum blockchain, a single mistake while creating your smart contract can cost you funds or, worse, the funds of those who use your application; the cost for these mistakes can be in tens or hundreds of millions of dollars. That's why testing is crucial.
We can use Solidity or JavaScript for smart contract testing. Thoroughly testing your smart contract is the only way to be confident it is valid, and that begins with smart contract unit testing.
The environment in which a smart contract is executed is immutable, so more emphasis is needed on testing it.
Now, why is testing important for smart contracts? First of all, contracts are high-risk programs running in blockchains. A bug in smart contracts can lead to extreme financial losses. For example, in the DAO.Hack, more than 11.5 million Ethers (like 70M USD at the time of the incident, now over 3B USD). A vulnerability in the Parity Mulisig Wallet version 1.5+ enabled an attacker to steal over 150,000 ETH from its users.
Many things can happen now that the TVL of DeFi space is expanding at a rapid pace; which means the DeFi application has much to lose. We can avoid these by performing as much testing as possible on the contract; we can perform unit testing on smart contracts, which allows examining if the individual parts are performing as intended and helps us identify edge cases and unexpected behaviour during the development cycle. This does not mean 100% assurance, but defending an attack rather than fixing the aftermath is better.
A program will always evolve based on requirements; this also applies to smart contracts. The need for an upgrade will always rise whenever new errors are discovered in a contract. However, this becomes a problem when we find an error but cannot solve it; this is especially true for smart contracts, which are inherently immutable.
Finding even the slightest error will force you to redeploy the smart contract, which will have dire consequences. We can compare smart contract development to hardware development because there is no easy way to upgrade after releasing both.
The upgradability of smart contracts exists to some extent. However, most contracts don't follow these mechanisms because the developers want to preserve the inherent immutability aspect of smart contracts or reduce the need for a governance mechanism.
One more important thing for upgradability of the smart contract is the consensus of the community, Therefore these are avoided unless it is inevitable.
In short, finding errors and potential bugs before the application launches is significant. This can be seen as the first line of defence.
