Feature/enhance docs (#1) (#120)

* fix: adding toc to testing modes md

* fix: adding toc for the common testing approaches md

Author: isk.eth

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). 

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: