Test suite

The existing testing suite used during the assessment is limited in its coverage and does not fully test all components of the smart contracts. This limitation prevented comprehensive testing and identification of potential issues, particularly in terms of negative testing scenarios. Some of the findings reported in this assessment like Findings ref↗, ref↗, and ref↗ could have been detected if the testing suite had been more comprehensive. To ensure the robustness of the smart contracts, we recommend that SoSoValue expands the testing suite to cover all functionality, including negative testing outlined in the threat model. Especially the Utils contract, which is used in many different places in the code and ensures many invariants, should be intensively tested and fuzzed.

Therefore, we recommend building a rigorous test suite that includes all contracts to ensure that the system operates securely and as intended.

Good test coverage has multiple effects.

• It finds bugs and design flaws early (preaudit or prerelease).

• It gives insight into areas for optimization (e.g., gas cost).

• It displays code maturity.

• It bolsters customer trust in your product.

• It improves understanding of how the code functions, integrates, and operates — for developers and auditors alike.

• It increases development velocity long-term.

The last point seems contradictory, given the time investment to create and maintain tests. To expand upon that, tests help developers trust their own changes. It is difficult to know if a code refactor — or even just a small one-line fix — breaks something if there are no tests. This is especially true for new developers or those returning to the code after a prolonged absence. Tests have your back here. They are an indicator that the existing functionality most likely was not broken by your change to the code.

Remediation

This issue has been acknowledged by SoSoValue, and additional tests were implemented in commit .