Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ethereum-tests error messages #3874

Open
2 tasks
ScottyPoi opened this issue Feb 21, 2025 · 0 comments
Open
2 tasks

ethereum-tests error messages #3874

ScottyPoi opened this issue Feb 21, 2025 · 0 comments

Comments

@ScottyPoi
Copy link
Contributor

ScottyPoi commented Feb 21, 2025

Continuing discussion from #3871.

Decide whether and how to use the expected error messages from ethereum-tests test vectors.

ethereum-tests include test instances meant to cause errors in execution, and include the type of error, or reason that it should fail, as part of the test vector. Currently, our test runners validate that an error has been thrown in these instances, but do not validate that the error thrown matches the expected error in the test.

One reason for this is that various optimizations result in errors being thrown as early as possible for invalid input, which can obscure the specific reason that the input was invalid.

For example, these two test instances use invalid input. Since we can invalidate the input based on size alone, we do not throw a specific error, but throw a size error:

expected = 'EOF_IncompleteSectionNumber'
actual = 'container size less than minimum'

and

expected = 'EOF_CodeSectionMissing'
actual = 'container size less than minimum'

In most cases, this mismatch will be the result of an optimization such as this. We want to preserve optimizations, and avoid altering our code to match a test vector. In rare cases, however, we may find ourselves "failing for the wrong reason", which would result in a test passing despite our code being incorrect.

Validating our errors against the test vectors is not as simple as applying a 1-to-1 mapping of expected errors to actual messages either, as we do end up with overlap in both directions.

--

One use case for these messages is to use them to inform when a test does fail. In these cases an error should have been thrown but wasn't. It would be helpful to debugging to have the expected error displayed when the test fails. i.e. Should have failed because of: ${_expected}

--

Todo:

  • apply expected error messages to test failure logs
  • design a way to validate that we are indeed passing "error" tests for the right reasons.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant