Content
@
0 reply
0 recast
2 reactions
Mo
@meb
A guide on writing smart contract unit tests. Bottom line; Aim for 100% coverage of your methods. Test what changes, who can call methods, events that are emitted and any validations you have. There’s more, but this provides a great foundation and forces you to think through things in a structured way. 4 categories of smart contract unit tests 1. effects - what state changed in the smart contract - did any balances change for related wallets or contracts? 2. permissions - which roles can call method? - who cannot call a method? - is this method callable if the contract is paused? 3. events - what events should be emitted and do they have the expected values? 4. validations - if a given set of conditions are not fulfilled, does the contract revert with a specific error? Be sure to check for the specific error, not just a revert
1 reply
6 recasts
24 reactions
nkemjika.eth
@nkemjika
Just got started on solidity and writing tests, it’s been a struggle, and takes me more time than writing the contract itself. But thanks for sharing this, bookmarked for reference.
2 replies
0 recast
2 reactions
Mo
@meb
Actually makes sense, contract code is pretty lightweight, but you need to spend a lot more time ensuring it’s bulletproof
1 reply
0 recast
2 reactions
Nico
@nicom
This is actually how all unit test work should be. People are not putting enough energy on writing tests for years and it makes others believe tests are the less interesting and fast part. But it's not. Test is what allows you to say that you did a good job on your code. That's the only metric that count. So put a lot of work in it. I would even recommend TDD (write tests first then the code to make them pass)
0 reply
0 recast
1 reaction
