Currently, the test framework doesn't know which opcode is under test or the expected number of opcode evaluations the test should perform. For example:
|
benchmark_test( |
|
code_generator=JumpLoopGenerator( |
|
setup=setup, |
|
attack_block=attack_block, |
|
cleanup=cleanup, |
|
tx_kwargs={"data": tx_data}, |
|
), |
|
) |
If we gave this information to the test spec, BenchmarkTestFiller, e.g., for the case of a "fixed opcode count" test (see #1834):
benchmark_test(
opcode_under_test=opcode, # in test_arithmetic.py, this is a test parameter
# after #1834 `opcode_count` is a test parameter; could be None for worst case tests (skip check or
# test framework specifies it automatically based on gaslimit.
expected_opcode_count=opcode_count,
code_generator=JumpLoopGenerator(
setup=setup,
attack_block=attack_block,
cleanup=cleanup,
tx_kwargs={"data": tx_data},
),
)then we could leverage evmone's --opcode.count bookkeeping functionality to verify the opcode evaluations during fill.
Currently, the test framework doesn't know which opcode is under test or the expected number of opcode evaluations the test should perform. For example:
execution-specs/tests/benchmark/compute/instruction/test_arithmetic.py
Lines 151 to 158 in 85c6fff
If we gave this information to the test spec,
BenchmarkTestFiller, e.g., for the case of a "fixed opcode count" test (see #1834):then we could leverage evmone's
--opcode.countbookkeeping functionality to verify the opcode evaluations duringfill.