mirror of
https://github.com/pezkuwichain/revive-differential-tests.git
synced 2026-04-29 00:48:01 +00:00
James Wilson
09d56f5177
* WIP redo how we parse and use modes * test expanding, too * WIP integrate new Mode/ParsedMode into rest of code * First pass integrated new mode bits * fmt * clippy * Remove mode we no longer support from test metadata * Address nits * Add ability for compiler to opt out if it can't work with some Mode/version * Elide viaIR input if compiler does not support it * Improve test output a little; string modes and list ignored tests * Move Mode to common crate * constants.mod, and Display for CaseIdx to use it * fmt * Rename ModePipeline::E/Y * Re-arrange Mode things; ParsedMode in format and Mode etc in common * Move compile check to prepare_tests * Remove now-unused deps * clippy nits * Update fallback tx weights to avoid out of gas errors * Update kitchensink weights too and fmt * Bump default geth timeout to 10s * 30s timeout * Improve geth stdout logging on failure * fix line logging * remove --networkid and arg, back to 5s timeout for geth
revive-differential-tests
The revive differential testing framework allows to define smart contract tests in a declarative manner in order to compile and execute them against different Ethereum-compatible blockchain implmentations. This is useful to:
- Analyze observable differences in contract compilation and execution across different blockchain implementations, including contract storage, account balances, transaction output and emitted events on a per-transaction base.
- Collect and compare benchmark metrics such as code size, gas usage or transaction throughput per seconds (TPS) of different blockchain implementations.
- Ensure reproducible contract builds across multiple compiler implementations or multiple host platforms.
- Implement end-to-end regression tests for Ethereum-compatible smart contract stacks.
Declarative test format
For now, the format used to write tests is the matter-labs era compiler format. This allows us to re-use many tests from their corpora.
The retester utility
The retester helper utilty is used to run the tests. To get an idea of what retester can do, please consults its command line help:
cargo run -p revive-dt-core -- --help
For example, to run the complex Solidity tests, define a corpus structure as follows:
{
"name": "ML Solidity Complex",
"path": "/path/to/era-compiler-tests/solidity/complex"
}
Assuming this to be saved in a ml-solidity-complex.json file, the following command will try to compile and execute the tests found inside the corpus:
RUST_LOG=debug cargo r --release -p revive-dt-core -- --corpus ml-solidity-complex.json