pezkuwichain/revive-differential-tests
1
0
Fork 0
mirror of https://github.com/pezkuwichain/revive-differential-tests.git synced 2026-04-22 07:57:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update the readme

Browse Source
This commit is contained in:
Omar Abdulla
2025-10-16 01:28:05 +03:00
parent bf35c084d4
commit 3ea2a58c8d
1 changed files with 4 additions and 178 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+4 -178
View File
@@ -52,195 +52,21 @@ All of the above need to be installed and available in the path in order for the
This tool is being updated quite frequently. Therefore, it's recommended that you don't install the tool and then run it, but rather that you run it from the root of the directory using `cargo run --release`. The help command of the tool gives you all of the information you need to know about each of the options and flags that the tool offers.
```bash
$ cargo run --release -- execute-tests --help
Error: Executes tests in the MatterLabs format differentially on multiple targets concurrently
Usage: retester execute-tests [OPTIONS]
Options:
-w, --working-directory <WORKING_DIRECTORY>
The working directory that the program will use for all of the temporary artifacts needed at runtime.
If not specified, then a temporary directory will be created and used by the program for all temporary artifacts.
[default: ]
-p, --platform <PLATFORMS>
The set of platforms that the differential tests should run on
[default: geth-evm-solc,revive-dev-node-polkavm-resolc]
Possible values:
- geth-evm-solc: The Go-ethereum reference full node EVM implementation with the solc compiler
- kitchensink-polkavm-resolc: The kitchensink node with the PolkaVM backend with the resolc compiler
- kitchensink-revm-solc: The kitchensink node with the REVM backend with the solc compiler
- revive-dev-node-polkavm-resolc: The revive dev node with the PolkaVM backend with the resolc compiler
- revive-dev-node-revm-solc: The revive dev node with the REVM backend with the solc compiler
-c, --corpus <CORPUS>
A list of test corpus JSON files to be tested
-h, --help
Print help (see a summary with '-h')
Solc Configuration:
--solc.version <VERSION>
Specifies the default version of the Solc compiler that should be used if there is no override specified by one of the test cases
[default: 0.8.29]
Resolc Configuration:
--resolc.path <resolc.path>
Specifies the path of the resolc compiler to be used by the tool.
If this is not specified, then the tool assumes that it should use the resolc binary that's provided in the user's $PATH.
[default: resolc]
Geth Configuration:
--geth.path <geth.path>
Specifies the path of the geth node to be used by the tool.
If this is not specified, then the tool assumes that it should use the geth binary that's provided in the user's $PATH.
[default: geth]
--geth.start-timeout-ms <geth.start-timeout-ms>
The amount of time to wait upon startup before considering that the node timed out
[default: 5000]
Kitchensink Configuration:
--kitchensink.path <kitchensink.path>
Specifies the path of the kitchensink node to be used by the tool.
If this is not specified, then the tool assumes that it should use the kitchensink binary that's provided in the user's $PATH.
[default: substrate-node]
--kitchensink.start-timeout-ms <kitchensink.start-timeout-ms>
The amount of time to wait upon startup before considering that the node timed out
[default: 5000]
--kitchensink.dont-use-dev-node
This configures the tool to use Kitchensink instead of using the revive-dev-node
Revive Dev Node Configuration:
--revive-dev-node.path <revive-dev-node.path>
Specifies the path of the revive dev node to be used by the tool.
If this is not specified, then the tool assumes that it should use the revive dev node binary that's provided in the user's $PATH.
[default: revive-dev-node]
--revive-dev-node.start-timeout-ms <revive-dev-node.start-timeout-ms>
The amount of time to wait upon startup before considering that the node timed out
[default: 5000]
Eth RPC Configuration:
--eth-rpc.path <eth-rpc.path>
Specifies the path of the ETH RPC to be used by the tool.
If this is not specified, then the tool assumes that it should use the ETH RPC binary that's provided in the user's $PATH.
[default: eth-rpc]
--eth-rpc.start-timeout-ms <eth-rpc.start-timeout-ms>
The amount of time to wait upon startup before considering that the node timed out
[default: 5000]
Genesis Configuration:
--genesis.path <genesis.path>
Specifies the path of the genesis file to use for the nodes that are started.
This is expected to be the path of a JSON geth genesis file.
Wallet Configuration:
--wallet.default-private-key <DEFAULT_KEY>
The private key of the default signer
[default: 0x4f3edf983ac636a65a842ce7c78d9aa706d3b113bce9c46f30d7d21715b23b1d]
--wallet.additional-keys <ADDITIONAL_KEYS>
This argument controls which private keys the nodes should have access to and be added to its wallet signers. With a value of N, private keys (0, N] will be added to the signer set of the node
[default: 100000]
Concurrency Configuration:
--concurrency.number-of-nodes <NUMBER_OF_NODES>
Determines the amount of nodes that will be spawned for each chain
[default: 5]
--concurrency.number-of-threads <NUMBER_OF_THREADS>
Determines the amount of tokio worker threads that will will be used
[default: 16]
--concurrency.number-of-concurrent-tasks <NUMBER_CONCURRENT_TASKS>
Determines the amount of concurrent tasks that will be spawned to run tests.
Defaults to 10 x the number of nodes.
--concurrency.ignore-concurrency-limit
Determines if the concurrency limit should be ignored or not
Compilation Configuration:
--compilation.invalidate-cache
Controls if the compilation cache should be invalidated or not
Report Configuration:
--report.include-compiler-input
Controls if the compiler input is included in the final report
--report.include-compiler-output
Controls if the compiler output is included in the final report
```
To run tests with this tool you need a corpus JSON file that defines the tests included in the corpus. The simplest corpus file looks like the following:
```json
{
"name": "MatterLabs Solidity Simple, Complex, and Semantic Tests",
"path": "resolc-compiler-tests/fixtures/solidity"
}
```
> [!NOTE]
> Note that the tests can be found in the [`resolc-compiler-tests`](https://github.com/paritytech/resolc-compiler-tests) repository.
The above corpus file instructs the tool to look for all of the test cases contained within all of the metadata files of the specified directory.
The simplest command to run this tool is the following:
```bash
RUST_LOG="info" cargo run --release -- execute-tests \
RUST_LOG="info" cargo run --release -- test \
--test ./resolc-compiler-tests/fixtures/solidity \
--platform geth-evm-solc \
--corpus corp.json \
--working-directory workdir \
--concurrency.number-of-nodes 5 \
--concurrency.ignore-concurrency-limit \
> logs.log \
2> output.log
```
The above command will run the tool executing every one of the tests discovered in the path specified in the corpus file. All of the logs from the execution will be persisted in the `logs.log` file and all of the output of the tool will be persisted to the `output.log` file. If all that you're looking for is to run the tool and check which tests succeeded and failed, then the `output.log` file is what you need to be looking at. However, if you're contributing the to the tool then the `logs.log` file will be very valuable.
If you only want to run a subset of tests, then you can specify that in your corpus file. The following is an example:
```json
{
"name": "MatterLabs Solidity Simple, Complex, and Semantic Tests",
"paths": [
"path/to/a/single/metadata/file/I/want/to/run.json",
"path/to/a/directory/to/find/all/metadata/files/within"
]
}
```
The above command will run the tool executing every one of the tests discovered in the path provided to the tool. All of the logs from the execution will be persisted in the `logs.log` file and all of the output of the tool will be persisted to the `output.log` file. If all that you're looking for is to run the tool and check which tests succeeded and failed, then the `output.log` file is what you need to be looking at. However, if you're contributing the to the tool then the `logs.log` file will be very valuable.
<details>
<summary>User Managed Nodes</summary>
@@ -283,7 +109,7 @@ sleep 5
# Run the tests (logs to files as before)
RUST_LOG="info" retester test \
--platform "$PLATFORM" \
--corpus ./corpus.json \
--corpus ./revive-differential-tests/fixtures/solidity \
--working-directory ./workdir \
--concurrency.number-of-nodes 1 \
--concurrency.number-of-concurrent-tasks 5 \