You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The path to a file containing the constructor arguments.
37
37
38
38
`--verify`
39
39
Verify contract after creation. Runs `spark verify-contract` with the appropriate parameters.
40
40
41
-
`--verifier`_name_
41
+
`--verifier`*name*
42
42
The verification provider. Available options: `etherscan`, `sourcify` & `blockscout`. Default: `etherscan`. Note: make sure you add "/api\?" to the end of the Blockscout homepage explorer URL.
43
43
44
-
`--verifier-url`_url_
44
+
`--verifier-url`*url*
45
45
The optional verifier url for submitting the verification request.
@@ -218,38 +218,38 @@ Dynamic linking is not supported: you should predeploy your libraries and manual
218
218
`--build-info`
219
219
Generate build info files.
220
220
221
-
`--build-info-path`_path_
221
+
`--build-info-path`*path*
222
222
Output path to directory that build info files will be written to.
223
223
224
-
`--root`_path_
224
+
`--root`*path*
225
225
The project's root path. By default, this is the root directory of the current git repository, or the current working directory.
Copy file name to clipboardExpand all lines: versioned_docs/version-1/spark/fork-testing.md
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -62,9 +62,9 @@ Forking cheatcodes allow you to enter forking mode programmatically in your Soli
62
62
63
63
#### Usage
64
64
65
-
Important to keep in mind that _all_ test functions are isolated, meaning each test function is executed with a _copy_ of the state _after_`setUp` and is executed in its own stand-alone EVM.
65
+
Important to keep in mind that *all* test functions are isolated, meaning each test function is executed with a *copy* of the state *after*`setUp` and is executed in its own stand-alone EVM.
66
66
67
-
Therefore forks created during `setUp` are available in tests. The code example below uses [`createFork`](../reference/cheatcodes/create-fork) to create two forks, but does _not_ select one initially. Each fork is identified with a unique identifier (`uint256 forkId`), which is assigned when it is first created.
67
+
Therefore forks created during `setUp` are available in tests. The code example below uses [`createFork`](../reference/cheatcodes/create-fork) to create two forks, but does *not* select one initially. Each fork is identified with a unique identifier (`uint256 forkId`), which is assigned when it is first created.
68
68
69
69
Enabling a specific fork is done via passing that `forkId` to [`selectFork`](../reference/cheatcodes/select-fork.md).
70
70
@@ -77,9 +77,9 @@ Similar to [`roll`](../reference/cheatcodes/roll), you can set `block.number` of
77
77
To understand what happens when a fork is selected, it is important to know how the forking mode works in general:
78
78
79
79
Each fork is a standalone EVM, i.e. all forks use completely independent storage. The only exception is the state of the `msg.sender` and the test contract itself, which are persistent across fork swaps.
80
-
In other words all changes that are made while fork `A` is active (`selectFork(A)`) are only recorded in fork `A`'s storage and are not available if another fork is selected. However, changes recorded in the test contract itself (variables) are still available because the test contract is a _persistent_ account.
80
+
In other words all changes that are made while fork `A` is active (`selectFork(A)`) are only recorded in fork `A`'s storage and are not available if another fork is selected. However, changes recorded in the test contract itself (variables) are still available because the test contract is a *persistent* account.
81
81
82
-
The `selectFork` cheatcode sets the _remote_ section with the fork's data source, however the _local_ memory remains persistent across fork swaps. This also means `selectFork` can be called at all times with any fork, to set the _remote_ data source. However, it is important to keep in mind the above rules for `read/write` access always apply, meaning _writes_ are persistent across fork swaps.
82
+
The `selectFork` cheatcode sets the *remote* section with the fork's data source, however the *local* memory remains persistent across fork swaps. This also means `selectFork` can be called at all times with any fork, to set the *remote* data source. However, it is important to keep in mind the above rules for `read/write` access always apply, meaning *writes* are persistent across fork swaps.
@@ -150,7 +150,7 @@ As mentioned each fork is essentially an independent EVM with separated storage.
150
150
151
151
Only the accounts of `msg.sender` and the test contract (`ForkTest`) are persistent when forks are selected. But any account can be turned into a persistent account: [`makePersistent`](../reference/cheatcodes/make-persistent).
152
152
153
-
An account that is _persistent_ is unique, i.e. it exists on all forks
153
+
An account that is *persistent* is unique, i.e. it exists on all forks
Copy file name to clipboardExpand all lines: versioned_docs/version-1/spark/invariant-testing.md
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -28,8 +28,8 @@ Invariants are conditions expressions that should always hold true over the cour
28
28
29
29
Examples of invariants are:
30
30
31
-
-_"The xy=k formula always holds"_ for Uniswap
32
-
-_"The sum of all user balances is equal to the total supply"_ for an ERC-20 token.
31
+
-*"The xy=k formula always holds"* for Uniswap
32
+
-*"The sum of all user balances is equal to the total supply"* for an ERC-20 token.
33
33
34
34
There are different ways to assert invariants, as outlined in the table below:
35
35
@@ -106,7 +106,7 @@ function invariant_example() external {
106
106
}
107
107
```
108
108
109
-
Another approach to handle different invariants across protocol states is to utilize dedicated invariant testing contracts for different scenarios. These scenarios can be bootstrapped using the `setUp` function, but it is more powerful to leverage _invariant targets_ to govern the fuzzer to behave in a way that will only yield certain results (e.g., avoid liquidations).
109
+
Another approach to handle different invariants across protocol states is to utilize dedicated invariant testing contracts for different scenarios. These scenarios can be bootstrapped using the `setUp` function, but it is more powerful to leverage *invariant targets* to govern the fuzzer to behave in a way that will only yield certain results (e.g., avoid liquidations).
0 commit comments