From 066b977c38a19e6f3e1960689a0f2436fb3c9980 Mon Sep 17 00:00:00 2001 From: iskanderandrews Date: Thu, 4 Aug 2022 11:37:32 +0200 Subject: [PATCH 1/2] fix: adding toc to testing modes md --- program-analysis/echidna/testing-modes.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/program-analysis/echidna/testing-modes.md b/program-analysis/echidna/testing-modes.md index c0fb4056..74572d21 100644 --- a/program-analysis/echidna/testing-modes.md +++ b/program-analysis/echidna/testing-modes.md @@ -2,6 +2,12 @@ Since Echidna offers several ways to write properties, often developers or auditors are wondering which testing mode should use. We will review how each mode works, as well as their advantages or disadvantages. +**Table of contents:** +- [Boolean properties](#boolean-properties) +- [Assertions](#assertions) +- [Dapptest](#dapptest) +- [Stateless vs Stateful](#stateless-vs-stateful) + ## Boolean properties By default, the "property" testing mode is used, which reports failures using a special functions called properties: @@ -110,7 +116,7 @@ function testStake(uint256 toStake) public { `testStake` checks some invariants on staking, but also ensures that the state of the contract is properly updated (e.g only allowing a user to stake at least `MINSTAKE`). -### Dapptest +## Dapptest Using the "dapptest" testing mode, Echidna will report violations using certain functions following how dapptool and foundry work: * This mode uses any function name with one or more arguments, which will trigger a failure if they revert, except in one special case. This is, if the execution reverts with the special reason “FOUNDRY::ASSUME”, then the test will pass (this emulates how [the `assume` foundry cheat code works](https://github.com/gakonst/foundry/commit/7dcce93a38345f261d92297abf11fafd6a9e7a35#diff-47207bb2f6cf3c4ac054647e851a98a57286fb9bb37321200f91637262d3eabfR90-R96)). This pseudo-code summarizes how dapptests work: From 8fcd9b8191142b9ef7a36bd09784300da6d47021 Mon Sep 17 00:00:00 2001 From: iskanderandrews Date: Thu, 4 Aug 2022 11:51:26 +0200 Subject: [PATCH 2/2] fix: adding toc for the common testing approaches md --- program-analysis/echidna/common-testing-approaches.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/program-analysis/echidna/common-testing-approaches.md b/program-analysis/echidna/common-testing-approaches.md index a7d8c9db..51e8e44a 100644 --- a/program-analysis/echidna/common-testing-approaches.md +++ b/program-analysis/echidna/common-testing-approaches.md @@ -7,6 +7,12 @@ we take care to avoid breaking some important underlying assumptions of transact That is why it is important to have a clear view of the system to test, and how transactions are going to be simulated. There are a few classifications for the testing approach. We will start by two them, internal or external: +**Table of contents:** +- [Common testing approaches](#common-testing-approaches) + - [Internal testing](#internal-testing) + - [External testing](#external-testing) + - [Partial testing](#partial-testing) + ## Internal testing In this testing approach, properties are defined inside the contract to test, with complete access to the internal state of the system. @@ -103,7 +109,7 @@ filterFunctions: [“MockERC20.mint(uint256,address)”] Finally, there is another benefit for using this approach: it will force the developer or auditor to write properties using public data. If an important property cannot be defined using public data, it could be an indication that users or other contracts will NOT be able to easily interact with the system to either perform some operation or verify that the system is in a valid state. -### Partial Testing +## Partial testing Ideally, testing a smart contract system uses the complete deployed system, with the same parameters that the developers intend to use. Testing with the real code, it is always preferred, even if it is slower than doing something else (but perhaps not in the case that it is extremely slow).