As an ambitious developer, how can you optimize the testing process of your dApp before making it available to the masses?
While speaking at ETHCC Paris, Paul Berg, the visionary builder and co-founder of Sablier, unveiled an innovative approach that revolutionizes the way developers test their dApps within the Ethereum ecosystem. Sablier is a Web3 streaming token built for Ethereum and other EMV-compatible chains.
Introducing Foundry, a remarkable smart contract development kit and Ethereum development environment.
Its rich array of tools empowers developers in constructing and deploying decentralized applications (dApps) effortlessly on the Ethereum blockchain.
Foundry comprises various powerful components. First, there’s Forge, a cutting-edge testing framework specially designed for Ethereum smart contracts. Then, we have Cast, an interactive tool enabling seamless interaction with EVM smart contracts.
Additionally, Foundry offers Anvil, an independent Ethereum node for local testing, and Chisel, an ingenious Solidity REPL to aid in rapid development.
Testing smart contracts with Solidity
In his talk, Paul highlighted the challenges of testing smart contracts using Solidity, which is an old language primarily used for web apps.
As smart contracts grow in complexity, testing becomes disorganized, leading to monolithic test contracts with no clear structure.
Developers are left with a contract that has a lot of paths, functions, and states, leaving them with monolithic test contracts, where the test has no structure.
To solve the problem of having an unorganized testing process, he recommended that the audience should get the material on Foundry by Matt Solomon.
In addition, Paul introduced a categorization approach for tests in Foundry to improve the organization and filtering of tests.
He categorized these tests into four different types: Unit, Integration, Invariant, and Fork.
Unit tests focus on a single contract, while Integration tests involve multiple contracts.
Invariant tests check for expressions that should always be true, and Fork tests are conducted against actual Ethereum mainnet contracts.
Furthermore, he explained that each test can be further divided into sub-categories: concrete tests and fuzz tests. Concrete tests are deterministic and have no inputs, resembling “hard-coded values” where the output matches the input. On the other hand, fuzz tests involve testing arguments that require different logic.
New easier testing technique
Paul introduced the “branching tree technique” for low-level design in testing, which was invented by his team.
This technique entails creating an English specification that outlines the contract state, function parameters, and establishes a hierarchy of potential execution paths for the function.
It is a straightforward and intuitive approach that can be easily understood by non-technical team members and potentially automated. As Paul puts it, “There’s no API. It’s just like using ASCII characters.”
The technique offers several benefits, including ease of learning, the ability to share with non-technical team members, and the potential for automating test file generation based on English specifications.
The speaker emphasized the importance of automatability in the tree technique system, as it represents the future of level testing in Solidity where automation plays a significant role.
In conclusion, Foundry emerges as a game-changer for Ethereum testing, simplifying the process and providing a structured approach for developers.
By utilizing the categorization and branching tree technique, developers can create more organized and powerful tests to ensure the reliability and security of their dApps on the Ethereum blockchain.
