With the increasing complexity ofprotocols, the importance of thorough testing cannot be overstated, especiallywhen it comes to the complex protocols and state transitions that arecommonplace in today's smart contracts.
Today we are talking the criticality ofachieving 100% test coverage in smart contracts, the limitations of thismetric, and the proactive steps developers can take to ensure the robustness oftheir protocols.
As protocols grow in complexity, the numberof potential state transitions
- that is, the various states a protocol canfind itself
- increases exponentially.
The simplest example of a state transitionis a staking contract where a state transition occurs when a user, say Alice,deposits tokens, changing the contract's state to reflect Alice's deposit.
Now if we think about contracts outside ofstaking contracts, such as lending protocols, whatsoever, it is critical tounderstand that the possible state transitions can go into the thousands andmore. Aiming for 100% test coverage is not just beneficial; it's mandatory.
This rigorous testing benchmark is aprerequisite for audits, ensuring that all basic scenarios are accounted forbefore deeper, more complex analyses begin. If fundamental scenarios containbugs, auditors may spend undue time addressing these rather than focusing onmore sophisticated state transitions and vulnerabilities.
However, achieving 100% test coverage doesnot guarantee that the contract is sufficiently tested. This metric can bemisleading: a line of code tested in one context is marked as fully covered,ignoring the hundreds of other contexts in which it could be executed. Such anarrow view of test coverage overlooks the nuanced, complex interactions thatcan occur within smart contracts, leaving potential vulnerabilities unchecked.This is what most developers lack knowledge and the actual reason why an auditis more than a simple “check”. After having covered the most obvious things, Icould literally spend months on large codebases to think about more statetransitions, this is why an audit is always a time-boxed review.
Developers must adopt a holistic approachto testing, extending beyond basic scenarios to consider intricate interactionswithin the contract. This involves contemplating various user actions—multipledeposits, sequential interactions like a call to updatePool followed by adeposit, partial withdrawals, and more. The more diverse and comprehensive thetesting scenarios, the lower the likelihood of undetected bugs. Creativityduring the testing suite is necessary here.
Moreover, it's not about if bugs will bepresent, but rather how many. This reality underscores the value of multipleaudits, particularly for intricate protocols.
Auditors, being human, have inherentlimitations in their ability to foresee every possible edge case or statetransition. A collective approach to auditing, involving multiple experts andteams, facilitates a broader examination of the protocol, leveraging sharedinsights to uncover and address potential vulnerabilities more effectively.
