stella3d
commented
2 years ago Some non-exhaustive notes on Solidity contract testing frameworks I'm familiar with:
-
Hardhat used to be quite popular for testing Solidity contracts, but now seems to be falling out of favor.
In hardhat, the tests are written in Javascript / Typescript instead of the contract language. This provides some benefits - many devs know JS, JS has great test tooling such as mocha. However it also comes with some type serialization issues that make things more difficult - It can be difficult to know exactly how to format a JS type so it's parsed as Solidity data correctly. JS testing is also slow because it's going through RPC calls, and it requires context switching from Solidity. -
Truffle offers testing in both Solidity and Javascript. The JS side is pretty much like Hardhat. The solidity tests are quite nice - they allow the dev to use one language & don't require much boilerplate.
-
DappTools & its improved version in Foundry are what's hot lately, for some good reasons:
- tests are written in Solidity
- implemented in Rust (it's much faster than other options)
- promoted by influential devs like Georgios Konstantopoulos
- capabilities no other test framework has, such as fuzz testing
From these, i think we can see that:
- JS / RPC based testing should be passed over in favor of pure Move tests
- All of these include a basic local chain that's setup for you
huitseeker
One fundamental limitation in the way we program Move is that, often when you create a new object and transfer it to someone, that object is no longer accessible from Move in the same call. To test something an entire flow of Move code, we need to make several calls to Move (see the hero test in authority_tests). This is inconvenient and not an accessible way of testing application code for Move developers. We need to come up with a framework that allows Move developers to test that code fully within Move.