Skip to content

[Docs]: Adding TOC for two README docs #120

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 31, 2022
Merged

[Docs]: Adding TOC for two README docs #120

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion program-analysis/echidna/common-testing-approaches.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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).
Expand Down
8 changes: 7 additions & 1 deletion program-analysis/echidna/testing-modes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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:
Expand Down