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
At present the expect section only has accounts and their attributes (balance, nonce, code, and storage). This means we can only test results that are visible to the evm.
It would be useful to have additional information available, which retesteth gets (or can get) from t8ntool. Specifically, we could use visiblity into:
Information from --vmtraceraw. For example, it might be useful to specify that when contract A is executed, when the program counter is B, the stack should have these values: [... , ... , ...], or that the gas spent between PC=x and PC=y is
a certain amount.
One requested feature was to have the logs entries available in a test (ethereum/tests#523). This would take care of that.
qbzzt
changed the title
Allow the except: section to have information that is invisible to the evm
Allow the expect: section to have information that is invisible to the evm
May 9, 2021
At present the expect section only has accounts and their attributes (balance, nonce, code, and storage). This means we can only test results that are visible to the evm.
It would be useful to have additional information available, which
retesteth
gets (or can get) fromt8ntool
. Specifically, we could use visiblity into:--vmtraceraw
. For example, it might be useful to specify that when contract A is executed, when the program counter is B, the stack should have these values: [... , ... , ...], or that the gas spent between PC=x and PC=y isa certain amount.
receipt.logs
, the log entries emitted. Right now so the only way to check what they are is to write a blockchain test and look in the hash of the block where they are emitted to see it is the expected value (see https://github.com/ethereum/tests/blob/develop/src/BlockchainTestsFiller/ValidBlocks/bcStateTests/logRevertFiller.yml). This method is very susceptible to false positives, because any other change in the block also changes the hash.receipt.transactionHash
, which lets us verify that everything ran as expected.The text was updated successfully, but these errors were encountered: